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NOTES & COMMENTS 


Editor^s Notes 


Editor’s Notes The editor’s notes for this November 1989 issue include the items of interest 

listed below. 

□ In Depth Special Features: The Sun386/ Administration Cookbook 

□ World hotlines for customer service calls 
p World-wide bug reporting information 

□ Limited permission to duplicate your STB 

o Hints and Tips: Saving backup time and determining DOS memory 

□ The Hackers’ Comer: FreeSpace 

□ Configurations: updated software release level tables, effective 
September 22,1989 

In Depth Special Features: The This month begins a three-month series of In Depth features which will include 

Sun386/ Administration the Sun386i Administration Cookbook. This first month includes the longest 

Cookbook chapter of immediate use to those customers running Sun386/ workstations: 

Chapter 9, Under the Hood. 

Future STB issues will include the cookbook table of contents, preface, the 
remaining chapters, an automounter appendix, and a separate cookbook 
index. 


STB readers should note that the pagination in the upcoming In Depth features is 
the same as in the cookbook. Simply remove the cookbook pages from the 
November, December, and January 1990 STBs and insert them in a separate 
Sun386/ Administration Cookbook binder. The remaining STB pages are 
paginated cumulatively as reflected in the STB Cumulative Index. 
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World Hotlines 


Reporting Bugs World-Wide 


STB Duplication Permission 


Hints and Tips 


For Sun customers world-wide served by your local service groups, use the 
customer service telephone numbers listed in this monthly item. Also, look to 
this section during the upcoming year for details on your local support call 
policies and procedures. 

A list of Sun service centers, addresses, email hotlines, and telephone hotlines 
appears. The information in this monthly note continues to be expanded as Sim 
software service centers are added world-wide. 

This notice is published monthly, giving customers useful information regarding 
ordering and duplicating additional STB copies. This duplication permission is 
limited, as detailed in the note. 

This month’s hints and tips section contains two new items of interest. The first 
is a hint on how to reduce the time needed to do backups for those running 
Sun386/ SunOS 4.0.2 on Sun386i machines. 

This month’s tips are on how to determine available DOS memory on Sun386/ 
machines, and possible uses of DOS extenders. 


The Hackers’ Comer This month’s Hackers’ Corner contains a FreeSpace tool of use to those 

wishing to sort through files to find which ones may be deleted to free disk space. 

For those with email access and wishing an online copy of Hackers’ Corner 
code samples, please email sunistb-editor or stb-editor@sun with your request. 
Please include the program title, and the STB issue month and year with your 
request. 

Again, please note that such applications, scripts, or code are not offered as 
released Sun products, but as items of interest to enthusiasts wanting to try out 
something for themselves. They may not not work in all cases, and may not be 
compatible with future SunOS releases. Please consult your local shell script or 
programming expert regarding any application, script, or code problems. 


Configurations: Current Sun 
Software Products and Release 
Level Tables 


The seven tables showing current Sun software product release levels appear 
monthly. These tables show release levels for operating systems, 
communications products, unbundled languages, unbundled applications, 
unbundled graphics, other products, and TOPS networking products. The tables 
in this issue are updated through September 22,1989. 


Thanks. 


The STB Editor 
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World Hotlines 


World Hotlines Sun Customers throughout the world have service hotlines available for both 

software and hardware support questions. The service hotlines are shown below. 
If your country is not shown in the table, please phone your local Sun sales 
office. 

The world hotlines are divided into those for Canada and the USA, CSD Europe, 
and Intercon. Intercon includes those countries outside the USA, Canada, 
Europe, and northern Africa. 

Canada and the United States 


Canada 

Montreal 

(514) 738-4885 


Ottawa 

(613) 723-8112 


Toronto 

(416) 477-6745 


Winnipeg 

(204) 222-2333 


Edmonton 

(403) 482-7264 


Calgary 

(403) 262-6722 


Vancouver 

(604) 684-4120 

United States 

All, 

including Puerto Rico 

1-800-USA-4-SUN 

CSD Europe 

European Customer Service 

Surrey 

Sun Microsystems Europe Inc. 

(44)276 51440 

France 

Paris 

Sun Microsystems France SA 

(33) 1 4094 8080 

Germany 

Munich 

Sun Microsystems GmbH 

(49) 089/46008-321 

The Netherlands 

Soest 

Sun Microsystems Nederland BV 

(31) 2155 24888 

Sweden 

Solna 

Sun Microsystems AB 

+46 8 76478 10 

Switzerland 

Zurich 

Sun Microsystems (Schweiz) AG 

(41) 1 828 9555 

United Kingdom 

Albany Park 

Sun Microsystems UK Ltd 

(44) 0276 691052 
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Intercon 

Australia 


Hong Kong 
Japan 

Countries Not Listed 


Sun Microsystems Australia 


Sun Hong Kong 


C. Itoh Data Systems 
Nihon Sun 

All countries outside the USA, 
Canada, Europe, northern Africa, 
Australia, and Japan 
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Reporting Bugs 



Submitting Bugs and Email 
Service Calls 


Submitting Software Bugs: 
United States and Canada 


This article contains two sections for submitting bugs. The first section describes 
procedures to use within the United States. The second section desaibes 
Customer Service Division (CSD) Europe procedures. 

This section contains information on reporting bugs within the U.S., for 
customers holding and not holding support contracts. 

Sun’s United States Answer Center (USAC) within CSD accepts software bug 
reports from Sun users via electronic mail and by phone. The method you use to 
submit a bug report varies with your needs. 

U.S. users holding support contracts can report bugs to USAC via the (800) 
USA-4-SUN phone hotline. Canadian users holding support contracts should 
call their local support center. The USAC phone hotline is the fastest way for a 
customer to find out if a problem is known and if a workaround exists. The status 
of previously-reported bugs can also be obtained in this way. The list of open 
software bugs is contained in the Customer Distributed BugsList (CDB). 

Customers holding support contracts can also submit bug reports electronically to 
the address sun'hotline {hotline@sm.COM). This method generates a service 
order, and can be used when lines of code or other information difficult to relay 
over the phone is needed to describe the bug. 

□ Whenever possible, customers should use the Online Bugs Database 
(OBD) described below before submitting bugs, to avoid resubmitting 
an already-known bug. 

□ Please note, however, that the alias onlinebugs-db@sun.com is not the 
appropriate avenue for submitting bugs. 

Customers who do not hold Sun software support contracts can report bugs via 
electronic mail to the address sun/sunbugs (or sunbugs@sun.COM). These 
reports are reviewed periodically to determine proper disposition. Those reports 
determined to be from supported customers are forwarded to the U.S. Answer 
Center for handling. Reports from customers who cannot be verified as holding a 
support contract are reviewed by Sun’s engineering and support personnel. An 
internal bug report is generated if the reported bug is new and verifiable. 

Finally, customers not holding software support contracts may call the (800) 
USA-4-SUN phone hotline to report a problem and request support on a Time 
and Materials (T&M) basis. Canadian customers should call their local support 
center. In this case, please have a Purchase Order (PO) number for billing 
purposes. 
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The Online Bugs Database 
(OBD) 


Information Provided by the 
OBD 


OBD Search Criteria 


The OBD contains the same information as the Customer Distributed BugsList 
(CDB). The information available through the OBD is updated during the first 
week of each month. As a result, you receive the most timely information 
available on open known bugs and temporary workarounds for Sun software in 
an easily-accessible, online format. 

The OBD service is initially available only within the United States. Future 
plans include worldwide introduction and distribution. 

The OBD provides you with rapid telephone access to the following information. 


□ Software Bug Reference Number-a unique identification number 
assigned to each valid software bug by Sun 

□ Online Bug Synopsis—a one-line summary of the software bug 

□ Bug Description—a brief description of the bug, with examples if avail¬ 
able 

□ Software release(s) in which the bug was reported 

□ Affected configurations 

D Temporary workarounds, where available 

To use the OBD, simply dial the telephone number and enter the system 
password; both provided in the Online Bugs Database Reference Manual, part 
number 812-1001. This manual is automatically sent to the site contact of all Sun 
customers holding valid support contracts. The OBD is available at all hours, 
except for scheduled updates and preventive maintenance. System support is 
available during standard U.S. Answer Center business hours by calling the 
support numbers given above. 

After logging in, you can quickly search the OBD by any one of the below 
parameters. 


□ Keyword(s) 

□ Software Bug Reference Number 

□ Software Category (such as kernel, SunINGRES, or Datacomm) 

□ Software Subcategory (such as documentation related to a specific 
category) 

□ Software Release (such as 4.0, 3.5, 3.4, 3.2,3.0) 
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Search capabilities can be enhanced by combining several of the primary search 
parameters. For example, all release 3.4 NFS bugs within the network category 
can be searched. In most situations, you can locate a particular software bug and 
its related workaround within 30 seconds. 

To ensure that your OBD use is as efficient as possible, a fast, easy-to-use Help 
facility is also provided. Help is available throughout your OBD session. 

For U.S. contract customers, (800) USA-4-SUN is the best method to report 
bugs. Canadian contract customers should report bugs to their local support 
center. The electronic mail address smlhotline is available to submit materials 
that are difficult to relay over the phone. The OBD is available to research 
currently-known bugs. 

For non-contract customers, the electronic mail address sunismbugs is available 
to report bugs. 

To help us serve you better, please include the following information with all 
electronic mail reports. 

□ Your name 

□ The name and address of your organization 

□ Your Sun site code, if available 

o Your workstation model and serial number 
o The software release(s) you are running 

□ A description of the problem that you are experiencing 

□ Please do not submit bugs to sm!onlinebugs-db 


Submitting Software Bugs: This section contains information on reporting bugs within CSD Europe, for 

CSD Europe customers holding and not holding support contracts. 

Procedures for submitting bugs are similar to those used in the United States. All 
customers should use their local country Answer Center to report bugs, with 
contract customers receiving a specific follow-up. 

Sun customers not holding software service contracts can call their local Answer 
Center, and will need to provide a Purchase Order (PO) number at the time of the 
call. 

Summary: CSD Europe To help CSD Europe service centers serve you better, please include the 

following information with all electronic mail reports: 


Summary: United States and 
Canada 
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□ Your name 

p The name and address of your organization 

□ Your Sun site code, if available 

□ Your workstation model and serial number 

□ The software release(s) you are running 

□ A description of the problem that you are experiencing 

Detailed information for European Customer Service and individual countries 
follows. 

European Customer Service The European Customer Service office is located at the address shown below. 

Sun Microsystems Europe, Inc. 

Bagshot Manor 
Green Lane 
BAGSHOT 
Surrey GU19 5NL 
United Kingdom 

Telephone: (44) 276 51440 

Telefax: (44)276 51287 

Telex: 859017 

France Report bugs to the France Answer Center at the postal address shown below. 

Service "HOT LINE" 

SUN Microsystems France 
La Boursidiere 
R.N. 186 

92357 Le Plessis Robinson Cedex 
Hotline Telephone: (33) 1 4094 8080 
Telefax: 0276 691774 


Special Dispatch Arrangements: 

Please provide Dispatch with the following items: 

System serial number or Contract number 
Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
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Germany 


The Netherlands 


Sweden 


Materials (T&M) basis, and order this support at the above 
address. 

Report bugs to the Germany Answer Center at the postal address shown below. 
Hotline 

Sun Microsystems Gmbh 
Stoerungsannahme 
Am Hochacker 3 
D-8011 Grasbrunn 1 
West-Germany 

Hotline Telephone; (49) 089/46008-321 

Telex: 5 218 197 sun 

Telefax: 089/46008-400 

Email Address: {sunuk,mido}!sunmuc!hotline 

Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 

Report bugs to The Netherlands Answer Center at the postal address shown 
below. 

Sun Microsystems Nederland BV 
Birkstraat 95-97 
3768 HD SOEST 
The Netherlands 

Hotline Telephone: (31) 2155 24888 

Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 

Report bugs to the Sweden Answer Center at the postal address shown below. 

Sun Microsystems AB 
Hemvamsgatan 9 
S 171 54 Solna 
Sweden 

Hotline Telephone: +46 8 764 78 10 

Email Address: hotline@sunswe.se or sunswelhotline 
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Switzerland 


United Kingdom 


Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 

Report bugs to the Switzerland Answer Center at the postal address shown 
below. 

Sun Microsystems (Schweiz) AG 
Postfach 

Rohrstrasse 36/38 
CH-8152 GLATTBRUGG 
Switzerland 

Hotline Telephone: (41) 1 828 9555 
Email Address: sunukisunswisfhotline 
Special Dispatch Arrangements: 

Provide Dispatch with the following item: 

Contract number 

Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 

Report bugs to the UK Answer Center at the postal address shown below. 

Hotline 

Sun Microsystems (UK) Ltd 

Technical Centre 

Unit 3D 

Albany Park 

Frimley 

Surrey 

GU15 2PL 

Hotline Telephone: (44) 0276 691052 

Telefax: 0276 691774 

Special Dispatch Arrangements: 

Please provide Dispatch with the following items: 

System serial number or contract number 
Arrangements for Non-Contract Customers: 
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Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 

Submitting Software Bugs: This section contains information on reporting bugs within Intercon, for 

Intercon customers holding and not holding support contracts. 

Procedures for submitting bugs are similar to those used in the United States. All 
customers should use their local country Answer Center to report bugs, with 
contract customers receiving a specific follow-up. 

Sun customers not holding software service contracts can call their local Answer 
Center, and will need to provide a Purchase Order (PO) number at the time of the 
call. 

Summary: Intercon To help Intercon service centers serve you better, please include the following 

information with all electronic mail reports: 

□ Your name 

□ The name and address of your organization 

□ Your Sun site code, if available 

□ Your workstation model and serial number 

□ The software release(s) you are running 

□ A description of the problem that you are experiencing 
Detailed information for individual countries follows. 
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Australia Report bugs to the Australian Answer Center at the postal address shown below. 

Hotline 

Sun Microsystems Australia Pty Ltd 
PO Box 320 
Artarmon 
NSW 2064 

Hotline Telephone: (011-61-2) 436-4699 

Telefax: 02 436 1084 

Special Dispatch Arrangements: 

Please provide Dispatch with the following items: 

System serial number or contract number 

Arrangements for Non-Contract Customers: 

Please provide a valid PO number for billing on a Time and 
Materials (T&M) basis. 
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STB Duplication 



Duplicatii^ the STB 


Direct STB Purchase 


Further Questions 


Your company’s software support contract includes a monthly issue of the STB. 
Each month, the copy of your STB is mailed to your company’s primary contact 
person or department. Sites with more than one contract may receive more than 
one STB copy, depending on how the contracts are set up. 

Your primary contact person or department may duplicate this ‘master’ STB 
copy for all Sun workstation end-users. So long as you duplicate copies and 
route them only internally, there are no copyright infringement problems. 

This limited permission for duplication is for your convenience only, however, 
and does not include any duplication for resale, for distribution outside your 
company, or for distribution to en^loyees of companies not having a Sun 
software support contract. 

The STB is sent to the primary contact person named in all software support 
contracts. Sun is looking into methods by which customers holding these 
contracts may purchase extra copies directly. 

Look to this column for an announcement regarding the purchase of extra STB 
copies. 

If you have any questions, comments, or articles regarding the STB or CDB, 
please send your ideas and questions to sunistb-editor. 
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ARTICLES 


calendar Network Traffic 



/bin/calendar Network In SunOS 4.x releases, /bin/calendar does a ypcat as well as cat 
Traffic /etc/pas swd to determine all possible users who have a -/calendar file. 

There are three problems caused by this process. 

Problem 1 Every 4.x machine is programmed in the crontab to wake up at midnight and 

perform ypcat. This triggers /bin/calendar to be executed for every 
ypcat entry. This affects the network traffic and YP slaves. 

Problem 2 When running automount to mount all possible home directories, the 

/bin/calendar tries to mount all of them, causing extra network load. When 
an NFS mount fails, the machine hangs because /home directories are typically 
mounted rw, hard . 

calendar does not function for a diskless client because all filesystems are 
NFS. Note that ‘calendar - ’ reports only if the -/calendar is in a local 
filesystem. 


Problem 3 Any machine that uses /etc/passwd as the master ASCII file reads the same 

information from ypcat passwd and cat /etc/passwd. This doubles 
the amount of calendar’s execution, and affects the network traffic and YP 
slaves. 


The Workarounds 
Diskless Clients 
Diskful Machine 


The following are offered as suggested workarounds. 

□ Disable the ‘calendar line from root’s crontab . 

□ Disable the‘calendar -’line from root’s crontab. 

o If the home directory is on a local disk, run calendar to create the 
user’s own crontab and include /bin/calendar. 
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Servers 


For servers, grep /'hostname'/ from the ypcat by replacing the line 
below: 

caldata="/bin/ypcat passwd.byname" 


with: 

caldata="/bin/ypcat passwd.byname | grep /'hostname'/" 

and by replacing the following line: 

$caldata |cat /etc/passwd - | grep -v |\ 


with: 

eval $caldata |cat /etc/passwd - | grep -v |\ 

YP Masters For YP masters using /etc/passwdasthemaster ASCII file, replace: 

$caldata |cat /etc/passwd - | grep -v |\ 

with: 

grep /'hostname'/ /etc/passwd - | grep -v '~[+-]' |\ 
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Diskless-Client Booting 



Diskless-Client Bootii^: In debugging client boot problems, it is important to determine in what stage the 

Debugging Network-Related failure exists and then debug from there. The three primary stages of the 

Problems diskless-client boot are listed below.^ 


1. The client PROM initiates a reverse arp ( rarp ) request to 
determine its IP address, and then executes a tf tp implementation to 
load the client boot program from a remote server ( /tf tpboot/^e). 

2. The client boot program implements RPC requests interacting with a 
bootparamd server to determine the network location of its remote 
disk filesystems (e.g. root and swap ), and then invokes the NFS 
protocol to mount a remote root filesystem and load vmunix . 

3. vmunix loads and initializes. 

Generally the console messages on the booting client suggest the current boot 
stage being processed and where the failure is occurring if the boot hangs. 
Debugging suggestions for the three boot stages are detailed below. 

Stage 1 Debugging A hang in stage 1 occurs when the diskless client boot cannot get an IP address, 

or gets an IP address but then fails during the tftp download of a boot 
program. The hang suggests that there are either server-side configuration 
problems or network problems that prohibit proper client/server interaction on 
the ethemet. 

Network packet tracing should be considered when related server configuration 
files (i.e. ethers, hosts ) and tftpboot links have been verified as 
correct, and the dependent server processes are available (i.e. rarpd, 
in.tftpd, inetd ). Packet tracing can be done easily by using the 
etherftnd(8C) command if another Sun machine that can serve as network 
monitor is on the same IP network. 


A failure with the rarp process will generally result in the below message 
appearing on the client console. 

Requesting Internet Address for ethemet address 


2 This article is submitted by Mark Allen, Manager, Data Comm Group, U.S. Answer Center, Mountain 
View, California, USA. 
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The above message suggests that the client is not receiving an rarpd reply to 
its request. As root on the Sun monitor machine, invoke the following command 
to monitor rarp interaction between the diskless client and a server. Then boot 
the the diskless client 

# etherfind -i interface -rarp 


The above command displays rarp packet activity. In a successful case, there 
should be an initial client rarp broadcast followed by a server reply to the 
client. If you see no activity, client ethemet problems are indicated. If a client 
broadcast is seen without a server reply, other ethemet problems affecting the 
server’s receiving the broadcast or problems affecting the server’s reply to the 
broadcast are indicated. 

After a successful rarp process, the client will make a tf tp request to obtain 
a boot block. Failure of the tf tp process will generally result in the following 
message on the client console. 

tftp: time-out 


Use the following etherfind command and arguments on the Sun monitor 
machine to monitor the tftp activity. The command monitors client-initiated 
tftp activity and any server responses. 

# etherfind -i interface -proto udp -src clientname -o -dst clieraname 


The same debugging logic applies here as in the previous rarp example. You 
are looking for expected client/server interaction, or otherwise noticing the 
direction of packet activity to determine the point of failure. 

Also look for any unexpected responses that might indicate incorrect server 
interaction. It is possible to have more than one machine on the net running 
rarpd . It is possible for more than one machine to reply to the client’s rarp 
request in cases where common ethers and hosts file information is 
shared. 

In such cases some booting delays occur since the client will first try to obtain a 
boot block by sending the tftp request to the machine that replied to the 
client’s rarp request However, that machine may not also be the tftpboot 
server for the client The client then broadcasts again to the network, looking for 
its tftpboot server. 

This rebroadcast can cause some client boot process delays. The first example 
etherfind command shown above uses the -rarp option and would show 
this case. It may help in determining if there are some unnecessary rarpd 
processes responding on the network. 
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Stage 2 Debugging 


Debugging failures in stage 2 includes those failures that occur after a client 
successfully boots through the rarp and tftp processes (stage 1), but fails 
prior to actually booting a vmunix (stage 3). A failure at this stage usually 
indicates problems during client interaction with the server’s 
rpc .bootparamd process. 

There are a number of interactions that occur during this stage. The best way to 
debug failures at this stage is to do the following. 

1. On the server side, kill and restart rpc. bootparamd with the debug 
-d option to the bootparamd(8) command. This may provide more 
verbose debugging information to help you determine why the failure is 
occurring. 

2. On the Sun monitor host, run ether f ind in RPC mode using the - r 
option. An example command appears below. 

# etherfind -i interface -r -src clientname -o -dst clientname 

The above command will likely capture a large amount of packet 
activity. It may not be immediately apparent where the problem is 
located, but this information can be forwarded to your local Sun service 
center for review. It can also be used for a conq)arison with a trace of a 
successful client boot case to help locate the failure point. 

It is important to note debugging messages from the server bootparamd 
process if etherfind shows some client and server interaction. These 
debugging errors may highlight more subtle problems occurring on the server- 
side if YP or DNS or both services are used. Error messages suggesting YP- or 
DNS-related service problems include those shown below. 

Whoami failed: gethostbyaddr for address 
bp_getclntent failed 
bp_getclntkey failed 


If the client’s server-side has a YP binding, then the server will make requests to 
a YP server to resolve hostname and bootparams information. Problems 
at the YP level (e.g. domainname, server not responding, bad map data) will 
prevent the client’s boot process from succeeding and should produce a debug 
error as shown above. 

If you suspect problems at the YP level, try configuring the client server with 
enough local file information (i.e. /etc/hosts , /etc/boot pa rams , 
/etc/exports ) to support the client boot without YP. Then kill the 
ypbind process and reboot the client. If the client boots successfully without 
the server running ypbind , then you know YP-related problems need 
debugging. 

Additional problems can be found at this YP level if the YP server has been 
configured to use DNS (Domain Name Service), causing client-hostname 
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Stage 3 Debugging 


Known Bugs: 1018583, 
1018791, and 1013639 


resolution at the DNS level. Client boot processes may not succeed if DNS 
service is intermpted or anomalies with hosmame matches exist 

If you suspect problems at the DNS level, you should make YP hosts maps with 
appropriate host information to allow the YP database to support hostname 
resolution and thus avoid DNS-related problems. Of course, the DNS-related 
problems should then be debugged and corrected. 

Once stage 2 network failures have been identified and fixed, the client should be 
able to successful NFS-mount its remote root and swap filesystems and boot 
a vmunix (stage 3). 

Diskless client boot failures in stage 3 usually suggest problems with the 
vmunix itself, problems with filesystem paths, or problems with client-space 
system files or daemons. This, however, can be a problem on any type system 
during this state of booting a vmunix. 

Generally, debugging at this level involves checking client-space filesystem links 
on the server-side, verifying a correct vmunix is being booted, and finally 
checking the client-space rc files for potential system initialization problems. 

Start by checking that the server’s /etc/exports file is exporting the correct 
filesystem paths with the correct access. Then verify that any links to a 
vmunix or /usr areas are correct. Finally, if you are using any common 
patches or custom programs that a client should also use, ensure that these 
modifications were also made to the appropriate client space. 

Diskless clients running SunOS releases 4.0.x having boot PROMS less than 
revision 3.0 can hang and ultimately fail during boot in cases where multiple 
boot servers are responding, or an improperly-implemented portmapper exists on 
the network. 

In these cases the client boot fails with the console often indicating an unusual 
sleep or exception message, or an RPC failure status. Patches are available 
through your local service center. 
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STB SHORT SUBJECTS 


Selection Service Messages 


Selection Service Message Customers may receive the message shown below from the selection service 

Defined which uses RPC calls. 

Request to current holder failed: RPC: Timed out 

This message may result from the network or CPU load on your machine, or 
from a race condition in the selection service. The race condition results when 
one window tries to notify the selection service that it has the primary selection 
while another window asks the selection service ‘Is there a primary selection 
right now?’ 

These two simultaneous requests collide, resulting in the time out of the RPC 
calls used by the selection service. 

The Workaround If the race condition is the problem, you can use the secondary selection instead 

of the primary selection. Press 1 L 81 while selecting the text. You will see an 
underline instead of reverse video. 

Please note that this message can also be a symptom of a network problem. 
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valloc failed Defined 

A 

V--- 

J 


valloc failed Message Customers trying unsuccessfully to get a window tool to come up may receive 
Definition the message shown below. 

pr_inakefromfd error: valloc failed 
pr_open: pixrect create failed for /dev/fb 


The Problem Defined The above message appears when there is insufficient swap space on the machine 

to start the tool. 

For example, in order to paint the screen, lockscreen and any other 
SunView program maps the frame buffer into its address space. In order to do 
this, the program first allocates memory equal to the frame buffer size and then 
maps the frame buffer on top of the memory. Once the frame buffer is mapped, 
the allocated memory no longer requires any swap space.^ However, it does 
require swap space until it is mapped. 

Customers seeing the above message have probably run out of swap space, so 
SunView programs cannot allocate memory on top of which to map the frame 
buffer. Swap space for data is allocated in sections that get larger as the data 
space gets larger. The swap space becomes fragmented, so that a contiguous 
section of memory large enough for the program may not be available, even 
when there are enough ‘fragmented’ spaces to make up the required size. 

A Workaround and A Fix Use the workaround or fix shown below, depending on how often this problem 

arises. 

□ Exit and reenter suntools. 

This frees swap space, so the ‘fragmented’ sections of memory no longer 
have allocated sections among them. When you reenter suntools, 
you may now have enough contiguous swap space to run 
lockscreen or other SunView programs. 

□ Increase the swap space. 

You may need to do this in case seeing the above message becomes a 
continual problem. 


^ Note that the allocated memory will require swap space after mapping the frame buffer in the unlikely case 
you have mapped something else on top of the allocated memory. 
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9.1 Introduction 

This chapter discusses the Sun386i file system, the woikings of Secure RPC, and the machinery 
of SNAP, Automatic System InstaUation, and New User Accounts. 

9.2 Inside the Sun386i File System 

If you are familiar with otter Sun systems and have woiked with Sun386i systems for any time at 
all, you know there are differences between the typical file system hierarchy on Sun-3, Sun-4, 
and SPARCstation systems and the file system as it is shipped on Sun386i disks. The Sun386l 
file system hierarchy was laid out differently to accommodate the needs of customers who: 

♦ Want a system that boots on delivery, with core software preloaded 

♦ Do not want hard limits on specific file systems (for example, /tmp) which could force a 
repartition 

♦ Require conpatibility with standard SunOS directories (/usr/bin, /usr/local, etc.) so 
that scripts and procedures can mn on all systems 

The first step in accommodating these goals was to divide Sun386i disks differently from the 
way Sun installation software typically sets up disks on Sun-3, Sun-4, or SPARCstation systems. 
The second step was “redirecting” some standard SunOS files and directories to take advan¬ 
tage of the new disk layout 

Comparing Partitions 

On most Sun systems, users must choose where they will allocate available disk space; the 
default in suninstall is to split user-available disk space between two roughly equal parti¬ 
tions. On Sun386i systems, the bulk of user-available disk space is in one partition (/files), 
so that growing files can compete equally for free space. The Sun386i arrangement guarantees 
that users never have to repartition their disks to gain more usable file space. 

Here is a comparison using two hypothetical system disks of 130 Mbytes: 




Partitions on a typical Sun-4 client’s disk Partitions on a Sun386i disk 

An explanation of these disk layouts is included on the next page. 
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root and swap - The default sizes of root and swap are approximately the same on both the 
Sun-4 and Sun386i disks. 

/usr - The Sun386i /usr partition stores Sun-supplied software and other system files. This 
partition is almost completely full and is mounted read-only. On other Sun systems, a large 
amount of user-available space is left in /usr, where user files and third-party software are of¬ 
ten stored. See “More About /usr” (page 117) for additional information on the Sun386i 
/usr partition. 

/files and /home - On a Sun386i system disk, the /files partition accounts for almost all 
of the user-available space. This partition houses many different types of files, including user 
files and home directories, optional SunOS commands, and files that are likely to grow or 
shrink such as temporary files or mail. 

On the Sun-4 disk, the additional partition is called home and most user file space is thus split 
between the usr and home partitions. 

An additional and sometimes confusing point is that Sun386i systems use /home as an auto¬ 
mount point for home directories. Other Sun systems do not use this automounting conven¬ 
tion by default. See “Inside the Automounter” for details. 

Compatibility between Directory Stmctures 

Although the Sun386i disk layout scheme solves many of a user’ s potential repartitioning head¬ 
aches, compatibility with existing SunOS file and directory locations was also required. For ex¬ 
ample, even though optional commands such as spell are stored in the Sun386i /files 
partition, users need them to appear in traditional locations such as /usr/bin so that exist¬ 
ing search paths, shell scripts, and ported software can ran across all Sun platforms. And even 
though space for files that grow or shrink is allocated to the files partition, users expect to 
see such files in standard SunOS 4.0 directories such as /var and /trap. 

The Sun386i file system thus “redirects” many traditional SunOS directories using standard 
SunOS features such as symbolic links and loopback mounts (new in SunOS 4.0). 

The figure below shows some of the differences between the file system layout found on the 
Sun386i and other Sun systems: 



Sun-3 under SunOS 4.0 



Sun386i under Sun386i SunOS 4.0 


(See the next page for an explanation of the directory types shown.) 
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Real directories - These are standard UFS directories. 


Symbolic links - All SunOS 4.0 file system layouts use symbolic links to maintain 
compatibility with older directory structures. A Sun386i system also uses additional 
symbolic lirdcs in lower directories (not shown here) for other reasons explained 
later in this section. 



Loopback mounts - These are special SunOS 4.0 mounts that perform a function 
similar to that of NFS mounts, except that they are not remote. Through loopback 
mounts, standard SunOS directories such as /tmp appear to users in their normal lo¬ 
cation (in /), even though the actual files are located in the Sun386i /files partition 
where more space is available. See “About Loopback File Systems” for details. 


■ Automount points - On Sun386i systems, files in /home, /vol, and /net are auto¬ 
matically mounted as needed. The automounter is available on all SunOS 4.0 sys¬ 
tems, but only Sun386i systems activate it by default. 


About Loopback File Systems 

The loopback file system is a new file system type available under all releases of SunOS 4.0. 
With a loopback file system, you can mount a local directoiy hierarchy on top of another local 
directory. This functionality is the local equivalent to mounting a remote directoiy using NFS. 

You can see how loopback mounts are used by comparing sample /etc/f stab files from 
Sun-3 and Sun386i systems. The default Sun-3 /etc/f stab file contains no loopback mounts, 
while the Sun386i /etc/f stab file has four: 



Loopback mounts 


lextedit - /etc/fstab (edited)^ dir: /home/mtravis 


-•‘[Scratch window 


/dev/sdOa / 4.2 rw^nosuid 1 1 
/dev/sdOg /usr 4.2 rw 1 2 
/dev/sdOh /home 4.2 rw 1 3 


textedit - /etc/fstab (edited)^ dir: /home/mtravii 


II I Scratch window 


Sun386i 


Tdev/roota / 4.2 rw 1 1 
/dev/rootg /usr 4.2 ro 1 2 
/dev/rooth /files 4.2 rw 1 3 

ij/export/tmp/localhost /tmp lo rw 0 0 
j/export/var/1ocalhost /var lo rw 0 0 
^/export/cluster/sun386.sunos4.0.1 /usr/cluster lo rw 0 0 
i /export/1Qcal/sun386 /usr/local 1o rw 0 0 

Mount this directory hierarchy... on/usr/local... using mount type lo (loopback). 
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Directories containing files that are likely to grow in size (/var or /tmp, for example) are set 
up in a file system where free space is available, and they are then loopback mounted onto the 
standard locations. Ultimately, these mounts resolve to subdirectories in /files (usually via 
symbolic links in /export), where they compete equally for available space in the partition. 

For such directories, loopback mounts offer the best of both worlds: Directories such as /tmp 
appear in their standard locations to a user, and yet really point to a partition where more 
ample free space is available. Traditional UNIX chores such as having to guess the high-water 
mark for directories like /tmp are no longer necessary. 

Although symbolic links might have been used for this kind of redirection, loopback mounts 
are preferable for two primary reasons: 

♦ Mount points for loopback mounts (for example, /var or /tmp) are real directories. They 
can still be used in the event that nothing is loopback mounted on top of them, as is the case 
when a system boots in single-user mode. 

♦ Loopback mounts are specific to a system. There is always a separate /etc/f stab file for 
every workstation since the root file system for each workstation is unique. In contrast, a 
symbolic link could be in a file system that is shared by many workstations—^potentially 
limiting file system flexibility. 

The Sun386i file system layout attempts to make optimum use of either loopback mounts or 
symbolic links, whichever is more appropriate in a given situation. Additional information on 
symbolic links is contained on the following pages. Also see “About /export” (page 114) for 
information on Sun386i exporting convention: i. 

Troubleshooting Loopback Mounts 

Here are some common problems with loopback file systems, and their solutions: 

mount_lo:Ho such file or directory - One of the two directories specified in the 
loopback mount line does not exist. Often this is because the directory is being mounted after 
the loopback mount entry in /etc/f stab. A loopback mount entry in /etc/fstabmustbe 
placed after the mount points of both directories it depends on. This is most easily accom¬ 
plished by placing the loopback mount entries at the end of /etc/f stab. 

mount_lo: No such device - Whenever you rebuild a Sun386i kernel, you must include the 
loopback file system in the kernel configuration, using the lofs option. This line is included 
in the preconfigured kernel. 

mount: Unknown file system type : lo - When the nu3unt(8) command encounters a 
file system type that isn’t built in, it starts a program called mount_filesystem_type. In the 
case of loopback mounts, this is mount_lo, which exists in /usr/etc; in the event of prob¬ 
lems with mounting loopback file systems, check that /usr/etc is in the path. (Note that the 
standard /etc/rc* files on Sun386i systems set the path correctly.) 

Because lo is simply another file system type, you can use it with any command that takes an 
fstype argument For example, here’s how to use df to get a list of mounted loopback file sys¬ 
tems: 

{system:!} df -t lo 
About /export 

On all Sun systems including the Sun386i, the /export directory is intended as a convenient 
organizing place for directories that will be exported to other systems. For example, 
/export/root/client is a standard SunOS 4.0 exporting convention on the boot servers of 
diskless clients. 

On Sun386i systems, symbolic links are used by convention to export file systems: The stan¬ 
dard “directories” in /export are actually symbolic links to other partitions (usually 
/files). 
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This scheme allows a central and standard place for exported files, while remaining tme to the 
goal of keeping most available free space in the /files partition. Customers are also encour¬ 
aged to create symbolic links from /export to any new partitions they add (/f ilesl, for ex¬ 
ample), and to use these symbolic links when exporting the new partition. 

Some of the symbolic links in /export resolve to directory hierarchies, which are in turn 
loopback mounted onto other local directories. 


For example, /export/tmp/localhost is a symbolic link to the directory 
. . /. . /f iles/tmp/localhost, which is in turn loopback mounted onto /tmp. 



While this combination of loopback mounts and symbolic links is confusing if you are trying to 
trace a particular directory to its source, the scheme can ultimately simplify administration of 
exported directories and disks. 

About Relative (..) Symbolic Links 

If you ever use Is -1 to examine directory symbolic links in the Sun386i file system, you’ll 
probably notice path names such as . . /. . /f iles/tmp/localhost. The . .’s in such path 
names are standard SunOS notation for a parent directory. They make this a relative symbolic 
link (as opposed to an absolute symbolic link, which specifies a path name starting with /), en- 
simng that the contents of the symbolic link can be properly evaluated even when examining a 
diskless client machine’s file systems from the server machine 

Mounting of Symbolic Links 

On all Sun systems, symbolic links are followed at mount time. When a mount request is madp 
for a directory such as /export/tmp/localhost, the symbolic link 
/export/tmp/localhost resolves to /f iles/tmp/localhost before the mount com¬ 
pletes. Thus, the system actually mounts the directory /f iles/tmp/localhost. 

Links in Action: Adding Extra Disks Through /export 

The convention of mounting symbolic links in /export is particularly effective for managing 
file systems on NFS servers. 

Moving existing directories from /f iles on a server to the new disk /f ilesl is relatively 
simple. NFS clients mount their files via the symbolic links in /export, so the only change re¬ 
quired is to move the files and then make the relevant symbolic links point to the new partition 
on the server. No change is required on any of the client systems. 
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For exanq)le, if a diskless client’s root were stored on /files, it would be in the directory 
/f iles/root/client_name (©) and there would be a symbolic link from 
/export/root/client_name (® )to it. The contents of the directory 
/f iles/root/client_name are moved to /f ilesl/root/client_name (®) and 
/export/root/client_name is made to point to this new location. 



S imilar ly, symbolic links for home directories are /export/home/groupname/usemame, 
and point to /f iles/horne/groupname/usemame. These symbolic links enable you to 
move home directories in a similar way, and enable home directories to be split over multiple 
disks. 

Additional Disk and the Use of /etc/where 

Once an extra disk is added to a system, it is possible to indicate to various daemons that the 
new disk is the one to use for the creation of new home directories or for support of new disk¬ 
less systems. This is done using the symbolic links in the directory /etc/where. 



Symbolic link to directories for 
new diskless clients (default is 
under /files) 


Symbolic link to location for new home 
directories 


The symbolic links for exec, root, and swap point to the directory in which to create a 
diskless client’s exec, root, and swap directories. By default these point to /files/exec, 
/files/root, and /f iles/swap. 
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By modifying these to point to, for example, /f ilesl/root, /f ilesl/exec, and 
/f ilesl/swap, the corresponding directories for new diskless clients added to the system 
via SNAP or Automatic System Installation will be created on the /f ilesl disk in the indicat¬ 
ed directories. You can also modify just one link (for instance, /etc/where/swap), so that 
new swap areas for diskless clients are created on one disk and their root and exec areas re¬ 
main on another. 

Similar links called home, local, and vol exist in /etc/where for home directories config¬ 
ured by SNAP or New User Accounts, and also for local software and optional software avail¬ 
able network wide. 

More About /usr 

The /usr partition on Sun386i systems is read-only, and contains only a core set of standard 
SunOS files. One benefit of this policy is that it discourages users from storing their own files in 
/usr, so that the /usr partition never fills up and requires repartitioning. 

Other advantages to /usr being read-only include: 

♦ Consistency among clients with and without disks 

♦ Increased stability and less chance of corruption to the /usr partition 

♦ Reduced boot time, since there is no need to mn f sck on /usr 

♦ Trouble-fiee sharing of /usr, since it is unlikely that /usr will have been modified or cus¬ 
tomized. 

As of SunOS 4.0, the /usr partition on all Sun systems has been set up to be architecture- 
specific; all files that are not architecture-specific have been moved to other partitions. This 
means that it is easy to share /usr between systems of the same architecture. On other Sun 
systems, the /usr partition is exported read-only so that systems that remotely mount /usr 
(such as diskless clients) do not have write access to the /usr partition. Sun386i systems take 
this one step further by mounting /usr read-only on both diskful and diskless systems, so that 
/usr is consistent between clients with and without disks. 

Third-Party Software and /usr 

One disadvantage to the approach taken with /usr on Sun386i systems is that third-party 
software may require you to install files in the /usr partition. Usually, you can install such 
software in tte /files partition, and set up a symbolic link or mount point to access the 
correct directory in /files. 

For more information, see “Installing Third-Party Software” in Chapter 5. 

Sharing /usr Among Clients 

A Sun386i client that has a disk, but shares /usr with another system, is called a diskful client. 
Sun386i systems have no automatic support for sharing /usr among clients with disks; 
however. Appendix C of Sun386i SNAP Administration explains how to acc omplish this easi¬ 
ly. Sharing /usr among clients with disks conserves disk space across the network, but has 
some performance implications because it creates more network traffic and a heavier load on 
the server where /usr resides. 

Performance of /usr 

Even though /usr is more than 100% full, its read-only status tenders it immune to the perfor¬ 
mance penalties that arise when allocating disk space on very full file systems. Because /usr is 
read-only, new blocks are typically not allocated in this file system and thus there is no inpact 
on performance in this partition. 
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Optional Clusters 

With Sun386i SunOS 4.0.2, all SunOS software is preloaded on the hard disk that is shipped 
with new Sun386i systems. 

To accommodate both the disk size and the desire to leave as much space free on the disk as 
possible, customers can unload all but the most critical pieces of SunOS, called Application 
SunOS core system. The rest of the operating system is divided into groups of files called op¬ 
tional clusters, which are available on separate media. Customers can unload or reload only 
those portions of SunOS that they need, thereby retaining more disk space for user or applica¬ 
tion fOes. 

(Note that when existing Sun386i systems are upgraded from 4.0.1 to 4.0.2, no additional 
clusters are loaded. Systems upgraded to 4.0.2 have the same clusters—in an upgraded form— 
that they had prior to upgrading.) 

All Those Symbolic Links 

To maintain compatibility with existing SunOS file system stmctures, every file in every 
Sun386i optional cluster has a symbolic link from its familiar file system location to its location 
on Sun386i systems. While the use of symbolic links may at times seem confusing, these links 
allow scripts and ported software to work identically across the Sun product line. After loading 
the aj^ropriate cluster, you can access files within clusters using the same path as on other Sun 
systems. 

For instance, the spell command is part of the loadable spell_check cluster. To a casual 
user, spell appears in /usr/bin. However, /usr/bin/spell is actually a symbolic link 
that points to /usr/cluster/appl/spellcheck/usr. bin/spell: 
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(Note that all clusters really reside in /files, which has the most fiee space; the 
/usr/cluster is actually a loopback mount that ultimately resolves to a directory stracture 
in /files. See “About Loopback File Systems” and “About /export” on pages 113 and 114.) 

Saving Disk Space with Clusters 

In a networked environment, users can mount the optional clusters via NFS from a cluster serv¬ 
er, saving even more disk space network wide. (See “Estabhshing Ouster Servers” in 
Chapter 6.) Sh^g the clusters among clients with disks saves disk space on the network as a 
whole; but sharing clusters also has performance implications because it creates more network 
traffic and a heavier load on the cluster server. 


9.3 Inside the Automounter 

The automounter is a standard SunOS 4.0 feature that provides automatic mounting of a file 
system upon first access. It is an NFS server designed to simplify access to remote file systems. 
With the automounter running, a user who wants to access exported files on other systems no 
longer needs to know the superaser password, or to understand the workings of /etc/f stab 
or mount(8). 

The automounter also makes life easier for administrators, who can move entire directory 
trees fiom one file server to another without having to update individual systems’ f stab files. 
Iiistead, mount points are defined in centrally accessible automounter maps. (If YP isn’t mn- 
ning, these maps can be distributed to individual machines by a mechanism such as cron(8).) 

The automounter can be used in addition to older mounting techniques: Mounting file hierar¬ 
chies with the automounter doesn’t preclude the use of mount(8) to mount hierarchies onto 
other directories in the traditional way. 

What the User Sees 

The casual user does not need to know the conventions of the automounter, and in fact does 
not even need to be aware that it is rutming. 

To take advantage of the automounter, a user simply changes to the automounted directory, or 
refers to the files directly via their path names—just as he or she would with any other file or 
directory. Here is a sample session with an automounted home directory: 

{system: 1} cd /home/mtravis 

{system:2} Is 

daily.articles/ weekly.articles/ monthly.articles/ 

(system:3} Is weekly.articles 
WSJ Barrens Fortune 

{system:4} Is /home/mtravis/weekly.articles 

WSJ Barrens Fortune 

For a technical explanation of what actually happens when you refer to a file or directory via 
the automounter, see Appendix A. 
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Standard Sun386i Automounted Directories 

The three standard automounted directories on Sun386i networks are: 

♦ /home - The path to users’ home directories, accessed as /home/usemame. Users can log 
into any machine running the automounter and be in their home directories. 

♦ /vol - Used for additional network-wide directories that a site administrator wants to set 
up. 

♦ /net - Used to access workstations on the netwoik, as /net/hostname/pathname. For 
performance reasons, /vol or /home is preferred over /net. However, /net can be useful 
for getting data from infrequently accessed machines whose files aren’t available throngh 
/home or /vol. 

Directories under /home, /vol, and /net are mounted only on first access. For instance, if 
you type Is /home/mtravis, the automounter mounts only mtravis’ home directory. 

To avoid a gradual buildup of remote mounts, the automounter unmounts file systems that 
have not been used for five minutes or more. 


How the Automounter Starts 

On Sun386i systems, the automounter is started at boot time by a set of hnes in 

/etc/rc. local. On other Sun workstations, users who want to use the automounter must 

start it themselves (as superaser) or add a similar line to rc. local. 

You can see how the automounter starts by examining these rc. local lines: 


textedit - /etc/rc.local 


^cratch window 
w 


if [ -f 7usr/etc/automount ]; then 

find /tmp_mnt/3i< -depth -xdev -type d -exec 
if ypmatch /vol auto.master > /dev/null 2>&1 
then . 


automount -tw 3Q0 && chat -n automount'" 



Check for YP automount map 


Start automounter using the 
auto.master YP map 


Start automounter using local files 


® T i . 

[automount -tw 300 -m /net -hosts /vol 7etc/auto,vol && chat -n 

automount'' 
fi 
f i 

if [ -f /usr/etc/in.rwhod -a -d /var/spool/rwho ]; then 
in.rwhod & 
chat -n '' rwhod'' 
fi 


Check for YP automount map - This line checks to see if a /vol entry exists in the YP 
auto. master map. It will pass this test only if YP is running and there is an auto. master 
map and there is an entry for auto. vol in that map. 

Start automounter using YP maps - If the YP / vol entry exists, the automounter starts 
using the default YP auto. master map. The - tw 300 entry sets a time-out of 300 seconds 
(five minutes) after which automounted file systems will be unmounted. If verbose boot 
messages are enabled (see Chapter 4), then the message automount is displayed on the 
screen. 

Start automounter using local files - If YP isn’t running, or there’s no auto. vol entry in 
the auto.master map, then this line tries to automount /net from the local /etc/hosts 
file, and to automount /vol from the local /etc/auto. vol file. 
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What’s in the Automounter Maps 

By default, a Sun386i system uses four standard automounter maps: auto .master, 
auto. home, auto. vol, and the special buOt-in map for hosts. 

The master Map 

The auto. master map contains entries for the various automount points and names the 
automount maps that will be used to manage those mount points. Unless you specify 
otherwise, the automounter attempts to read this map when it starts. The default Sun386i 
auto. master map includes entries that define the maps for /home, /vol, and /net: 


textedit - /etc/auto.master, dir: /etc 


Scratch window 

Inc. 

/net uses the automounter*s 
built-in -hosts flag 

/home uses the auto.home map 
/vol uses the auto.vol map 



Note that the default options for all three file systems specify nosuid. This practice eliminates 
the possibility of a user gaining superuser privileges on a variety of hosts via the automounter. 
If an suid mount option is necessary, specify it in the mount options of a particular map entry 
in auto. vol or auto. home, and this will override the default set up in the auto. master 
map. 


Home Directories and auto.home 

The auto. home map lists the mount points for users’ home directories. This file is updated 
when user accounts are created through SNAP and New User Accounts, and also when SNAP is 
used to move or delete user accounts. As you can see, the automounter is capable of mounting 
home directories from any home directory server 


textedit - /etc/auto-home (edited), dir: /etc 


Scratch window 


# key mount-options location 

# 

mtravis - oak:/export/home/users/mtravis' 

Juser ^ - grumpy :/export/home/users/juser 

ahinkle - 1 qcs:/u/accts/ahinkle — 


Accessed as... 
/home/ahinkle 
/home/juser “ 
/home/mtravis. 


Sun386i home directories 
exported from oak and grumpy 
via /export 

Home directory on system gcs, 
stored in a directory called Ai 


On Sun386i home directory servers, home directories generally reside in /f iles/home or 
/f ilesl/home (the expansion unit disk) but the convention is to mount them via symbolic 
links in /export/home as shown in the example. 
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Network-Accessible Directories and auto. vol 

The /vol hierarchy is useful for automounting “volumes” such as groups of DOS applica¬ 
tions, source code, or third-party software, /vol is a Sun386i convention. 

As shown in the example below, the auto. vol map lists the mount points for /vol: 


textedit ~ /etc/auto.vol (edited), dir: /home/mtravis 


Scratch windouj 


# key mount-option 

# 


help -ro 
heIp.master 
arch Ives 
dosapps 


i... 

irsG 


Accessed as. 
/vol/dosapps 
/vol/archives — 
/vol/help.master 
/vol/help - 


location 


cl eo :/usr/hi/hel p 
cleo:/usr/h1/help 
gep petto:/export/archive 
pinocchi 0 :/export/apps/dos 


comment 


Mount options here override 
“those in auto.master 


# HELP, Juser 

# HELP, juser 

# archives, MIS 

# dos stuff, mtravi^ 


\ 


Comments are useful for tracking use 
and identifying local administrator 


As shown in this example for the /vol/help entry (which is mounted read-only), you can 
specify mount options to override the default mount settings. 


Automounting from Non-Sun386i Home Directory Servers 

On Sun-3, Sun-4, and SPARCstation systems mnning SunOS 4.0, conventionally /home is a 
UFS mount point and users’ home directories are specified as: 

/home/servemartK/usemame 

To automount a such a home directory: 

♦ Ensure that the passwd map specifies /home/usemame in the home directory field. 

♦ Use the following format in the auto. home map: 

username servemame:/home/servemame/usemame 

The above steps will give access to this home directory on all machines that run the 
automounter using that auto. home map. You will need to perform the following additional 
steps on machines that do not run the automounter: 

♦ Mount the home directory via mount(8) and f stab(5). You can mount it on 
/home/servemame/usemame, or in another convenient location. 

♦ Create a symbolic link from /home/usemame to where the home directory is mounted 

With this method, you are using the Sun386i convention for the home directory name across 
all your systems. 

Running the Automounter on Non-Sun386i Home Directory Servers 

The above procedure works in most cases, but won’t woik if you ran the automounter with the 
auto. home map on servers where the /home/servemame/usemame directory actually re¬ 
sides. An alternate solution is to rename all /home partitions in 4.0 servers to /files or 
some other designation of your choosing. The auto. home entry for ahinkle would then 
look like this: 

ahinkle servemame :/files/servemame/ahinkle 
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By renaming the /hcame partitions on home directory servers, the automounter can be ran on 
all systems—including home directory servers—^without conflicting with existing UFS mount 
points. 

If you rename home directories in this way, remember also to change the home directory field 
for each affected user in the pas swd maps. 

Again, this method is using the Sun386i convention for the home directory name across all 
your systems. 

Troubleshooting the Automounter 

The following are frequently encountered problems and their solutions. 

Can’t access all files on a remote system - The automounter mounts only exported file 
systems. So, certain directories that you can see by remotely logging in to a system typically 
won’t be available. 

Solution: Either export the file system you need to access, or use commands such as rep and 
rsh to access the files directly. 

/net doesn’t show any files on some systems - The automounter cannot access files on 
diskless systems or on systems that are not NFS servers. This is because such systems do not ex¬ 
port their files. For example, you can’t use the automounter to access files and directories on a 
PC running PC-NFS. 

Slow performance of /net - /net mounts every exported file system when accessing a 
given server, so it is slower than /vol. Use a /vol path if it is available. 

Unusual path names such as /tmp_innt/home/mtravis - On all Sun platforms, the 
automounter shows symbolic links to temporary mount points when you use pwd or other com¬ 
mands. By default, Sun386i systems hide this by setting the adt0M0UNT_FIXNAMES environ¬ 
ment variable to true in new users’ . login files. The automount_fixnames setting is used 
by getwd() to prevent the /tmp_mnt prefix from showing. If you notice unusual automounter 
paths, check to make sure that automount_fixnames is set. automodnt_fixnames is a 
Sun386i-only feature. 

Can’t find file that it previously opened - Because the automounter periodically unmounts 
idle file systems, certain programs may be unable to re-access files that were opened via a 
/tinp_mnt-style path name. 

Solution: Make sure automount_fixnames is set to TRUE on Sun386i systems (see above). 

Doesn’t recognize new maps added to auto. master - In certain cases, you may want to 
add new automounter maps by setting up additional entries in auto .master, editing the YP 
Makefile and then remaking YP. The section on “Setting Up a Cluster Server’’ in Chapter 6 
shows an example of how to do this. 

You can modify the automounter maps at any time, but keep in mind that the automounter 
only looks at the master map when you run the automount(8) command, which is normally 
started at bootup on Sun386i systems (when they read /etc/rc. local). Therefore, to use a 
map modification immediately, restart the automounter on each system that needs to take ad¬ 
vantage of the new map. 

hostname:filesystem already mounted on mounipoint - The automounter has 
mounted a file system on a directory that already had a file system mounted on it. This hap¬ 
pens if an entry in an automounter map also appears in a system’s /etc/f stab file (either by 
accident or because the output of mount -p was redirected to f stab). 

Solution: Delete one of the redundant entries. 

trymany: servers not responding: reason- No server in a replicated mount list is 
responding. This may indicate a network problem, or that a 4.0.1 automounter is running with 
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a map that specifies replicated server entries. (Replicated server entries were not supported in 
Sun386i SunOS 4.0.1.) 

Remount hostnameifilesystem on mountpoint: server not responding -The 
automounter attenqited a remount after an unmount failed. Indicates a server problem. 

HFS server (pidn(amountpoint) not responding still trying - An NFS request 
made to the automount daemon with process ID n serving mountpoint has timed out The au¬ 
tomounter may be temporarily overloaded or not active. 

Solution: Wait a few minutes. If the condition persists, the easiest solution is to reboot the 
client 


A 


Diskless clients and the automounter - Diskless clients must always mount their 
root, swap, and usr partitions via mount(8) even if they use the automounter to 
mount some file systems. 


9.4 Secure RPC 

All SunOS 4.0 networks mnning YP provide the Secure RPC facility, a new feature of remote 
procedure calls that includes a mechanism for secure authentication of users and systems. 

Secure RPC enables servers to verify the identity of their clients. 

The Secure RPC facility works exactly the same on all Sun workstations. 

Services that use Secure RPC verify the identity of their clients before executing the requested 
procedure on behalf of those clients. On Sun386i systems, for example, the IP address 
allocation daemon is contacted by both SNAP and Automatic System Installation (ASI). The 
rpc. ipallocd service validates the user invoking SNAP or ASI before performing the 
requested IP address allocation. 

Services using Secure RPC include: 

♦ Sun386i agents and allocator daemons that SNAP, ASI, and New User Accounts use 
(rpc.uid_allocd, rpc.gid_allocd, rpc.ipallocd, rpc.pnpd, and 
rpc.useragentd) 

♦ YP updating (ypbatchupd), except for the yppasswd(l) program 

Any user accessing one of these services is validated with the default key (nobody) shipped 
with the system, or with a unique key if an administrator or user has created one with the 
newkey(8) or chkey(l) command. Similarly, superuser contact from a system to one of these 
services is validated with the default key, or with a unique key. If a user or the superuser on a sys¬ 
tem does not have a unique key, these Secure RPC requests use the default (nobody) key. If the 
default key is deleted from the system, then users who rely on the default key are unable to 
access any services using Secure RPC. The “Keys and YP Maps” section provides more infor¬ 
mation. 

^ By default, when a system is added via ASI, a unique key is set up for root of that system. 
Conversely, when a system is added via SNAP, no unique key is set up for root 

Neither SNAP nor the New User Accounts feature creates a unique key for a new user 
when setting up the account. 
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RPC Authentication 

The basic RPC mechanism is a request/response protocol; the client sends a request to the 
server, and receives a response. The requests include information describing the request 
(RPC service number, procedure number, arguments), the requestor (authentication and veri¬ 
fication information), and a transaction ID. The response includes the transaction ID used 
with the request (to distinguish between responses), information used to verify that the server 
is really the right server, and the response data. 


Client 


Master Server 



Request 


RPC service #, procedure #, arguments. 
Client authentication/verification 
Transaction ID 



Client 


Master Server 



Response 


Transaction ID, 
Server verification 
Response data 



Keys and YP Maps 

Programs that use Secure RPC to communicate with other processes validate users by checking 
the publickey. byname YP map. This map is based on the contents of the file 
/etc/publickey on the YP master. The publickey. byname map contains an entry for 
each user and system on a network if (and only if) a unique key has been set up for that user or 
system. A system entry is used as an entry for that machine’s root, so the map can contain an 
entry for each regular user and each root user (one per system) on the network. Clients and 
servers using Secure RPC generate “conversation” keys based on publickey. byname en¬ 
tries. 

Each map entry in publickey. byname consists of a network name and a public and private 
key. Network names, also known as “net names,” have the following format: 

Unix . userID(aYP_domain_name for users 

Unix . system_name@YP_domain_name for superuser (root) 

Each private key is DES encrypted with the user’s (or root’s) password. Each public key is gen¬ 
erated from the private key. By default, the password used to encrypt the private key is the 
same as the login password. 

Because of the encryption scheme, you should only add entries to the publickey maps with 
the chkey(l) or newkey(8) commands. Do not edit the /etc/publickey file by hand ex¬ 
cept to delete entries or to re-enter the default key as described in “Public Key Manipulation 
and Storage” on page 128. 
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nobody Default Key 

Each Sun386i YP master contains a default key, called nobody, in the publickey. byname 
map. The map contains other entries only if: 

♦ A system has been installed with ASI, in which case publickey. byname has a unique entry 
for the superuser (root) on that system 

♦ A user or administrator creates a unique key with the chkey(l) or newkey(8) command for 
a given user 

If no unique key is assigned to a user or root, the nobody key is used instead. The nobody key 
offers less security than individually assigned keys since the all-null password for nobody is 
well known; it is possible for clients or servers to impersonate other machines and issue or ac¬ 
cept secure RPC calls. 

If the entry for nobody is changed or deleted, users or root without their own entries in the 
publickey. byname map will be unable to communicate with processes that use Secure RPC. 
If you delete the nobody entry, you can retrieve it by entering: 

system:SUPERUSER:1} grep nobody /usr/etc/unconfigure 

Then add the entry to /etc/publickey on the YP master and remake the map 
(cd /var/yp / make). This is the only entry you should ever add by hand to the 
/etc/publickey file, since the password for nobody is unencrypted (all nulls). 

netld•byname Map 

Secure RPC also uses the netid. byname YP map, which contains privileges generated from 
the password, group, and host YP maps. Privileges that are stored in netid. byname can be 
of two types: 

♦ A DID and a list of GIDs; for example, 1037:12,260,4,14,42,37,2359 

♦ Superuser for a host; for example, 0: heliiun. East. Sun. COM (If you log in as root and is¬ 
sue a Secure RPC, your net name will be the host name.) 

By default, only the net names of users and supemsers of systems in the local YP domain are 
listed in this map, but requests from other domains can be authenticated and granted 
privileges (see Chapter 8, which discusses administering multiple domains). 

The keyserv Daemon 

The keyserv daemon must know your decrypted private key so that a conversation key can 
be created when you contact a service using Secure RPC. 

When a user logs in, login(l) or logintool(8) decrypts the private key and password and 
then gives the result to the keyserv(8C) daemon. The keyserv daemon stores information 
on this in the /etc/keystore file. It also stores information in the /etc/keystore file if a 
user enters the keylogin(l) command with the correct password necessary to decrypt the us¬ 
er’s private key. 

You can give the private key information for root to the keyserv daemon by first killing the 
keyserv daemon, and then invoking the keyserv -n command. This command creates the 
/etc/. rootkey file, which stores the private key for root. The /etc/. rootkey file enables 
root on a system to use Secure RPC prior to the validation that occurs at login time (this feature 
is used by the daemons). 
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Troubleshooting Secure RPC 

Secure RPC is transparent to users, but there are failure modes that are visible to users. These 
failures are usually due to mistakes in manipulating the new publickey databases used by Secure 
RPC; the details of those databases have not been well documented. 

As delineated in this section, most Secure RPC problems can be corrected by performing 
both of the following steps: 

♦ Deleting keys for users and root (except nobody) from the /etc/publickey file in 
multiuser mode and rebuilding YP 

♦ Deleting the /etc/keystore and /etc/. rootkey files in single-user mode and 
rebooting 

You can then recreate keys with the chkey(l) or newkey(8) command, and have users log out 
and back in again to reregister their keys with the keyserv daemon. If you don’t re-create the 
unique keys and register them after deleting nondefault keys and the keystore and 
. rootkey files, everyone will use the nobody key. 

Authentication problems while mnning applications — If a network administrator de¬ 
letes a user’s entry from the /etc/publickey file on the YP master and rebuilds YP, or if a 
user changes it with the chkey(l) command, various RPC applications (such as secure NFS or 
SNAP) might generate errors with RPC credentials or verifiers. The problem will often go away 
if, ill single-user mode, you delete the file /etc/keystore from the system where the user 
logged in, and then reboot. 

After invoking /usr/etc/chkey to change the keys for a user or root (or deleting keys by edit¬ 
ing /etc/publickey), make sure the right private key is in use by having the user (or root) 
log out and log back in again. As an alternative, users can change the private key in use by run¬ 
ning /bin/keylogin. 

^ keylogin(l) and the Domestic Kit - In Sun386i SunOS 4.0.1, a bug requires that you 
install the Domestic Kit if you want to use keylogin(l). This bug is fixed in 4.0.2. 

Autlientication problems with systems (root) — Similarly, you could see RPC errors af¬ 
ter deleting the public key entry for root from the /etc/publickey file. To avoid these error 
messages after deleting a system’s root public key entry, in single-user mode delete the 
/etc/. rootkey file, which stores root’s private key, and the /etc/keystore file. Then re¬ 
boot the system. 

User or administrator forgets public key password — If you can’t remember the correct 
public key password for an account, you can set the password and assign a new public key data¬ 
base entry by logging in to the YP master as root and invoking /usr/etc/yp/newkey for the 
user (or root). Note that on Sun-3 and Sun-4 systems this path is /usr/etc/newkey. 

Decryption messages — If your public key password and login password are different, you 
will see decryption error messages when logging in on Sun386i SunOS 4.0.2 systems. To pre¬ 
vent display of these messages, make your public key password the same as your login pass¬ 
word; this is required for your home directory to be mounted properly if it is NFS mounted 
using the secure option and Secure NFS. 

Public key errors while running SNAP— If you can log in as yourself, but you receive pub¬ 
lic key errors while adding a user in SNAP, the problem generally is with the system to which 
you’re adding the user account. Since you logged in successfully, your user public key data is 
corr(xt. To avoid display of these error messages, delete the public key entry for root of the 
system you’re trying to reach (to do so, edit the /etc/publickey file on the YP master, and 
remiike YP). Then, in single-user mode on that same system, delete the /etc/. rootkey and 
/etc/keystore files and reboot. 
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newkey: Command not found — On Sun-3 and Sun-4 systems, the newkey command is 
stored in /usr/etc, which is in the supemser’s default path. On Sun386i systems, the newkey 
command is stored in /usr/etc/yp, which isn’t in the default path. To run newkey on 
Sun386i systems, use the full path name to the command. 

^ Problems logging in — logintool used to prevent users from logging in if the login 
password and public key password involved in user authentication were not identical, or 
if a user’s password was longer than eight characters. This problem is fixed in Sun386i 
SunOS 4.0.2. 

Workaround for 4.0.1 — Users can make their public key passwords the same as their 
login passwords with the chkey(l) command, being sure to use a login password that is 
no longer than 8 characters. They then must log out and back in again to reregister the 
new public key. 

Keys established by SNAP — As of Sun386i SunOS 4.0.2, user accounts created with 
SNAP do not have public key or private key information automatically set up for thera 
SNAP does, however, correctly maintain accounts that use public keys. 

Public Key Manipulation and Storage 

Since YP is available only in multiuser mode, you must perform most key operations in 
multiuser mode. This includes changing user or root passwords, since those usually involve re¬ 
encrypting the private key in the public key database. The only exceptions to this are deleting 
the /etc/keystore and /etc/. rootkey files, which you should do in single-user mode. 

Creating a Public Key Entry 

Users can establish or change their own public key information by invoking the chkey(l) com¬ 
mand, and logging out and back in again. (However, if the passwords are different, the user 
wUl see decryption warning messages when logging in.) 

As a network administrator, you can assign public key information for users and root with the 
/usr/etc/yp/newkey command on the master YP server. For root, you also must issue the 
/usr/etc/keyserv command with the - n option to create the /etc/. rootkey file. See 
the on-line man pages for details on these commands. 

Never add or delete individual /etc/. rootkey or /etc/keystore entries; delete only the 
files, if necessary. You can delete individual /etc/publickey entries, but do not add en¬ 
tries to this file except to re-enter the default nobody key if it has been deleted. See “nobody 
Default Key” (page 126) for instmctions. 

Deleting a Public Key Entry 

To delete the public key database entry for a user or root, delete the applicable entry in the 
/etc/publickey file on the YP master and rebuild YP. If you delete a root entry, you must 
also delete the /etc/. rootkey and /etc/keystore files on that system, in single-user 
mode. When you delete a public key entry for a user or root, the default nobody key entry is 
then used for Secure RPC requests. 

^ keystore(5), . rootkey(5) — There are no on-line or hard-copy man pages describ¬ 
ing the /etc/keystore and the /etc/. rootkey files. 

Reference: Security Features Guide (Chapter 6) 

On-hne Sun386i SunOS 4.0.2 man pages (man_pages optional cluster must be 
loaded) — chkey(l), newkey(8), keylogin(l), keyserv(8C), publickey(5) 
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9.5 Network Time Synchronization 

Each Sun workstation uses a clock to keep track of the time and date. These clocks continue to 
run even when the power is off. Sun386i systems on Sun386i networks try to keep their clocks in 
close synchronization, using the following mles: 

♦ If configuration probing is enabled on a client system, that system sets its clock from its boot 
server each time it boots, via the /sbin/netconf ig command. 

♦ Boot servers try to set their clocks from the timehost (the master server, by default) when 
they boot. If boot servers cannot do this, they display a message suggesting that you check 
the clock time. 

♦ Time on the timehost is maintained by timehost’s system clock, and is adjusted manual¬ 
ly when necessary. 

If your network clocks do not show the correct time, first check that the timehost clock is cor¬ 
rect by issuing the following command: 

system:SUPERUSER:1} rsh timehost date 

To resynchronize any system’s clock if the time is only slightly wrong, use the rdate(8C) com¬ 
mand. If the discrepancy between the time shown and the actual time is more than a few min¬ 
utes, and your system has configuration probing enabled, you can simply reboot the system to 
reset the time. 

Any system on the network can be designated the timehost. Just change the YP hosts (or 
the system’s /etc/hosts) definition for timehost to the system you want to use. By default 
on Sun386i networks the timehost is the master server. 

It’s important to keep all system clocks closely synchronized, because NFS relies on time 
stamps to indicate when it must get updated file information from the server. Other network 
applications, as well as users, rely on system-supplied time and date infoimation. 

On non-Sun386i systems, users must use rdate manually to keep systems up to date. If you are 
using your Sun386i system on a Sun-3/4 network, then you should ensure that the clock is set 
correctly in the same way, because your Sun386i system most likely does not have configura¬ 
tion probing enabled. (Configuration probing requires a Sun386i YP server. See “Sun386i 
Probing” in Chapter 5 for detaOs.) 


Additional Steps for Reconciling Time Differences on a Master or Standalone 
If the date and time on a standalone system or the master server for the network differs from 
the actual date and time by more than a few minutes, enter the following additional com¬ 
mands after resetting the time using the date command (or rdate, if the timehost is not 
the master): 


system :SUPERUSER:1} 
system :SUPERUSER:2} 
system :SUPERUSER:3} 
system :SUPERUSER:4} 


cd /var/yp 

rm *.time *.push 

make 

exit 


If you set the date or time on the master server, reboot the boot servers and then reboot all the 
other systems on the network for this change to take effect throughout the network. 
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9.6 Inside SNAP, ASI, and New User Accounts 

Automated systems that aspire to ease of use must by their nature hide much complexity. So it 
is with Automatic System Installation, New User Accounts, and SNAP. 

Sun386i networks use the same underlying mechanisms and setup files as other Sun networks. 
However, because SNAP, Automatic System Installation (ASI), and New User Accounts are au¬ 
tomated, it’s not always obvious exactly what files have been updated when. In addition, 

Sun386i ease-of-administration features rely on some new features not found on other Sun 
systems: 

♦ Additional YP updating support via ypupdate(3), for use by ASI 

♦ A YP updater, rpc. ypbatchupd (described in ypbatchupd(8)), for use by SNAP and 
logintool(8). This daemon updates YP maps, and also performs a locking service to pre¬ 
vent SNAP users from updating the same maps simultaneously. 

♦ A “home directory agent,” rpc. user_agentd (described in user_agentd(8)), for use 
by SNAP and logintool(8) 

♦ Daemons for allocating various network identifiers such as uid_allocd(8C), 
gid_allocd(8C), and ipallocd(8C). The ipallocd(8c) daemon is used by ASI and 
SNAP to allocate unique IP addresses to new systems being installed on the network. The 
uid_allocd and gid allocd daemons allocate new user and group IDs, respectively. 

♦ RARP (Reverse Address Resolution Protocol) daemon support (rarpd(8)) for Dynamic 
RARP (Internet standards are not yet finalized). Automatic System Installation uses the 
modified RARP daemon and DRARP to assign addresses to systems trying to install them¬ 
selves, and to report errors encountered while assigning those addresses. 

♦ pnpd(8C) for automatic system installation, which includes the “diskless agent” for use in er¬ 
ror recovery (client(8C) and SNAP also use this agent). The pnpd(8c) daemon looks up 
configuration information for systems at boot time, and also communicates requests to the 
master server when a new system is installed. 

♦ tf tpd(8C), modified for Automatic System Installation of diskless systems 

♦ Miscellaneous YP improvements such as ypsync, which collects the most current YP maps 

This section explains the procedures used by SNAP, Automatic System Installation, and New 
User Accounts. Chapter 10 outlines the contents of various files associated with Sun386i net¬ 
working. 

Diagnosing Errors 

In the event that something goes wrong, Sun386i ease-of-administration tools generally 
produce appropriate error messages: 

SNAP errors - For SNAP, read the diagnostic messages in the alerts, and choose the Why? 
button for more detail. In some cases the Why? button expands to several levels of detail. 

logintool and New User Accounts errors - For errors that occur during account creation 
from logintool(8), see the file /var/adm/mes sages on the local system if it has a disk, or 
on the server if the system is diskless. 

Eirors at bootup - Errors that occur at boot time and during Automatic System Installation 
are listed in the /var/adm/messages file. See the Sun386i Field Service Manual for expla¬ 
nations of error codes that appear in this file and on the screen. 

If you want to see traditional SunOS messages when booting, you can turn on the system’s ver¬ 
bose message mode. See Chapter 4 for details. 

For help diagnosing errors, see the applicable sections of Sun386i SNAP Administration. 
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Adding a Network Client Through SNAP 

The process of adding a network client through SNAP happens in two stages. 

In Part A, SNAP updates the appropriate YP maps with information about the new system. In 
Part B, shown on the following pages, the new system sets up its own local configuration files 
based on the information that SNAP has placed in the YP database. 


Pan A - What SNAP Docs 


SNAP performs the following procedures when you add a new network client. The headings be¬ 
low match those from the diagram. 

Read YP Maps - As soon as you select the Systems category, SNAP reads the YP maps for the 
various files listed in the diagram. Files in parentheses () are read but will not be rewritten. 

Allocate IP Address - You can assign your own EP address for a system by specifying the ad¬ 
dress in SNAP. If you leave the system number address field in SNAP blank, new IP addresses 
are assigned automatically by a daemon (ipallocd). To prevent possible duplicates, this 
daemon also matches the generated address against existing addresses listed in the hosts and 
ipalloc. netrange maps, and against an internal cache of all current IP address client re¬ 
quests on the network. 

Update YP Maps - The listed files are completely rewritten, with additional entries now includ¬ 
ed for the new system. The same daemon that updates these files (rpc. ypbatchupd) then re¬ 
makes YP, distributing the new maps to all slave servers. 

Part A Complete - At this point, the network is prepared to recognize the system when it is 
added to the network. SNAP rereads the YP maps and is ready for the next operation. You can 
quit SNAP or leave it running—all the requisite YP files for the new system are now up to date. 
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What Happens When You Add a Network Client via SNAP 
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Continued on the following pages. 
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Part B - What Happens When a User Starts the System 


Before it is turned on, all a new system “knows” about is its Ethernet address. The Ethernet ad¬ 
dress for each system is recorded in the hardware, and is guaranteed unique for each system. 
The remainder of the information required to install the system is obtained from the network. 

Once you have prepared the network for the new system, the new system performs the follow¬ 
ing tasks when someone turns it on for the first time. 

Connected to Network? - The system probes to see if it is connected to the network. 

Get IP Address - The program /sbin/netconf ig, started from /etc/rc. boot, broad¬ 
casts a Dynamic RARP (DRARP) request for the IP address of this system. This program deter¬ 
mines that the client has not yet been installed by looking at a special flag (must_SETUP) in 
/etc/net.conf. 

Look up Client - The first server (master or slave) to answer the request becomes the tempo¬ 
rary boot server that will provide the IP address to the new client. 

The rarpd daemon mnning on the boot server uses the client’s Ethernet address as a key to 
look up the system’s assigned IP address. The IP address is then returned to the client. 

How the lookup works: The daemon first matches the Ethernet address with an entry in the 
YP ethers . byaddr map to determine the chent’s host name. (For this reason, the ethers 
maps on Sun386i networks contain the Ethernet address of every machine on the network.) 

The daemon then uses this host name to look up the client’s IP address in the YP 
hosts. byname map. 

For additional notes on the ethers and hosts maps, see Chapter 10. 

Probe for Configuration Information - Once the netconf ig program knows the IP ad¬ 
dress, it sends out a request for additional configuration information such as the name of the 
domain, and the host name. Again, the first server to answer becomes the temporary boot 
server that manages the configuration information. 

Return Configuration Information - The pnpd daemon on the boot server looks up con¬ 
figuration information, and passes it back to netconf ig on the client system. 

Set Up Local Files - Based on the information gathered during configuration probing, the 
client creates and updates its /etc/net. conf file, and then creates the additional files 
shown in the diagram. As part of the procedure, the special must_setup flag is removed 
from /etc/net. conf. 

Part B Complete - The system is now fully installed. It finishes booting and then displays the 
login prompt. 
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Installing a Network Client via ASI 

The process of adding a new network client involves three systems: 

♦ The master server, where maps are updated and the name and IP address of the client is 
allocated 

♦ The boot server, from which the new system gets some initial configuration infonnation. 
The boot servers in steps 6,8,9a, and 10 can actually be different systems, but their role in 
each of these steps is to provide setup information for the new client. 

♦ The new network client, which issues the configuration requests. 


Wililt ASI Does 


Automatic System Installation perfonns the following procedures when you add a new network 
client. This diagram assumes that the domain ip_address_allocation policy is set to 
drarp_only, and the pnp pohcy is set to unrestricted (the defaults on Sun386i networks). 

To begin with, all a new system “knows” about is its Ethernet address. The Ethernet address for 
each system is recorded in the hardware, and is unique for each system. The remainder of the 
information required to install the system is obtained from the network. 

The headings below match those from the diagram. 

Connected to Network? - The system probes to see if it is connected to the network. 

Request IP Address - The program /sbin/netconf ig, started from /etc/rc. boot, 
broadcasts a Dynamic RARP (DRARP) request for the IP address of this system. This program 
determines that the client has not yet been installed by looking at a special flag (MUST SETUP) 
in /etc/net. conf. 

Recognize Client as New - The first server (master or slave) to answer the request becomes 
the temporary boot server that will manage IP address allocation to the new client. 

The RARP daemon running on the boot server uses the client’s Ethernet address to attempt a 
lookup of the system’s IP address from the ethers and hosts maps. Not finding an entry for 
the system (since it hasn’t yet been installed), the server recognizes the client as new and re¬ 
quests a new IP address from the master server (see next heading). The RARP daemon then 
broadcasts this IP address to the network to double-check that no other systems are using it. 

(Note that this broadcast validation is only done when adding a system through ASI—^this 
double-checking is not performed by SNAP.) 

Allocate IP Address - New IP addresses are assigned automatically by a daemon (ipallocd) 
that generates an address, and then matches it against those listed in the hosts and 
ipalloc. netrange maps as well as against an internal cache kept by the ipallocd 
daemon. 

Probe for Configuration Information - Once the netconf ig program knows the IP ad¬ 
dress, it broadcasts an RPC request for additional configuration information such as the name 
of the domain, the host name, and the time zone. 

Recognize as Unconfigured - Again, the first server (master or slave) to answer the request 
becomes a temporary boot server that will provide initial configuration information to the 
new client. 

The pnpd daemon running on the boot server uses the client’s Ethernet address as a key to 
look up the system’s assigned IP address. The daemon first tries to match the Ethernet address 
with an entry in the YP ethers. byaddr map to determine the client’s host name. Because 
this is a new system, an entry will not exist for it, and the daemon will inform the new client 
that it is not yet set up in the YP maps. 

(continued) 
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What Happens When You Add a Network Client via ASI 
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Installing a Network Client via ASI (cont’d) 

Ask to Be Configured - The client broadcasts an RPC request to acquire a server, and ac¬ 
cepts the first response from the pnpd daemon on a willing boot server. The client then issues 
an RPC request to be set up by the server. 

Configure System - The pnpd daemon on the boot server issues a request to the master 
server to set up the required maps, and then returns the domain name, host name, time zone, 
and network role to the client. 

Allocate Name - Names are assigned from the /etc/pnp. sysncunes file. See 
pnp. sysnames(5) for details. 

Update YP Maps - Entries for the new system are added to the listed files on the master server. 
The same daemon that updates these files (rpc. ypupdated) then remakes YP, distributing 
the new maps to all slave servers. 

Set Up Local Files - Based on the information gathered from the configuration request, the 
client creates and updates its /etc/net. conf file, and then creates the additional files 
shown in the diagram. 

Client Boots - The system is now fully installed. It displays its name and domain, finishes 
booting, and then displays the login prompt. 

ASI Without a Network 

On a standalone system the procedure is the same, except that all of the master server and 
boot server operations take place on the new system. A Sun386i standalone system is effective¬ 
ly a “network of one system.” 

ASI for Setting Up a Master Server 

As on a standalone system, the procedure for setting up a master server is basically the same as 
for setting up a network client. 

Exceptions: The contents of some files are different, and all operations in the diagram take 
place on the system you’re setting up as the master server. 
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Adding a Diskless Client Through SNAP 

The process of adding a diskless client through SNAP really happens in two stages. 

In Part A, as shown in the diagram, SNAP updates the appropriate YP maps with information 
about the new system. In Part B, shown on the following pages, the new system sets up its own 
local configuration files based on the information that SNAP has placed in the YP database. 

See Sun386i SNAP Administration (June 1989 Edition) or the on-line Sun386i Help Viewer for 
further information on how to add diskless clients via SNAP. 

Assumptions When Running SNAP 

Before adding a diskless client through SNAP, you must have already enabled the boot server 
via SNAP to accept an additional diskless client. 

(If the intended boot server isn’t enabled, or isn’t set up to accept more than the diskless 
clients it currently serves, its name will be dimmed in the Bootserver menu and you won’t be 
able to add the diskless client to it. 

Additionally, if no boot server can accept any more diskless clients, the Diskless Client entry 
in the Network Role menu will be dimmed, and you won’t be able to select it. 

Use the slide bar in a server’s SNAP profile to indicate how many diskless clients that server will 
accept.) 


Pan A - What SNAP Does 


SNAP perfoims the following proceduies when you add a new diskless client. The headings be¬ 
low match those from the diagram. 

Read YP Maps - As soon as you select the Systems category, SNAP reads the YP maps for the 
various files listed in the diagram. Files in parentheses () are read but will not be rewritten. 

^ Note that SNAP can read files from any YP server, including slaves. As of 4.0.2 it no 
longer tries to bind to the YP master. 

Allocate IP Address ~ You can assign your own IP address for a system by specifying the ad¬ 
dress in SNAP. If you leave the system number field in SNAP blank, a new IP adless is as¬ 
signed automatically by a daemon (ipallocd). To prevent possible duplicates, this daemon 
also matches the generated address against existing addresses listed in the hosts and ipal - 
loc. netrange maps, and against an internal cache kept by the ipalloc daemon. 

Set Up System Directories - The pnpd daemon (rpc. pnpd) sets up system files for the 
diskless client in various subdirectories under /export on the boot server. These directories 
are added to the diskless client’s /etc/exports file and exported. Also added to the client’s 
/etc/exports and /etc/f stab files are /usr, /usr/cluster (if applicable), and 
/usr/local. 

(Note that the entries in /export are really symbolic links to directories in other locations, as 
determined by entries in /etc/where. See page 116 for details.) 

Set Up tf tpboot Link - The pnpd daemon sets up the link to the appropriate boot file for 
this SunOS version and architecture. 

Update YP Maps - The listed files are completely rewritten, with additional entries now 
included for the new system. The same daemon diat updates these files (rpc. ypbatchupd) 
then remakes YP, distributing the new maps to all slave servers. 

Part A Complete - SNAP rereads YP maps and is ready for the next operation. At this point, 
the network is prepared to recognize the system when it is added to the network. You can quit 
SNAP or leave it mnning. All the requisite YP files for the new system are now up to date. 
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What Happens When You Add a Diskless Client via SNAP 
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Pai1 B - What Happens When a User Starts the System 


Once you have prepared the network for the new system, the new system performs the follow¬ 
ing tasks when someone turns it on for the first time. The headings below match those from the 
diagram. 

Connected to Network? - The system probes to see if it is connected to the network. 

Request IP Address - The PROM broadcasts a Dynamic RARP (DRARP) request for the IP ad¬ 
dress of this system. 

Look up Diskless Client - The first server (master or slave) to answer the request becomes 
the boot server for the diskless client. 

The rarpd daemon mnning on the boot server uses the client’s Ethernet address as a key to 
look up the system’s assigned IP address. The IP address is then returned to the diskless client. 

How the lookup works: The daemon first rrratches the Ethernet address with an entry in the 
YP ethers . byaddr map to determine the chent’s host name. The daemon then uses this 
host name to look up the client’s IP address in the YP hosts. byname map. 

Standard Boot Sequence - The PROM initiates the standard diskless boot sequence. 

Standard Boot Interaction - The boot server performs normal boot steps. See boot(8) for 
details. 

Probe for Configuration Information - Once booting has begun, rc. local starts 
/sbin/netconf ig, which broadcasts an RPC request for additional configuration informa¬ 
tion such as the name of the domain, the host name, and the time zone. 

Set Up Local Files - Local files for a diskless client are stored on the boot server in 
/export/root/diskless_client/etc. Based on the information gathered during configura¬ 
tion probing, the client creates and updates its net. conf file, creates the passwd file and 
writes the root password (the encoded hostid) into it. The client then creates the additional 
files shown in the diagram. 

Part B Complete - The system is now fully installed. It finishes booting and then displays the 
login prompt. 
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Adding a Diskless Client Through ASI 

The process of adding a diskless client involves three systems: 

♦ The master server, where maps are updated and the name and IP address of the client is 
allocated 

♦ The boot server, from which the diskless client boots and where all its local files are stored 

♦ The diskless client, which issues the initial boot and configmation requests 


What ASI Docs 


Automatic System Installation performs the following procedures when you add a new diskless 
client. The headings below match those from the diagram. 

Connected to Network? - The system probes to see if it is connected to the network. 

Request IP Address ~ The PROM broadcasts a RARP request, which will receive no response 
because the diskless client is new and thus is unknown on the network. The PROM then broad¬ 
casts a Dynamic RARP (DRARP) request to get its IP address of this system. 

Recognize Client as New - The RARP daemon mnning on the boot server recognizes the cli¬ 
ent as new and so requests a new DP address from the master server (see next step). The RARP 
daemon then broadcasts this IP address to the network to double-check that no other systems 
are using it. (Note that this broadcast validation is only done when adding a system through 
ASI—^this double checking is not performed by SNAP.) 

AUocate IP Address - New network addresses are assigned automatically by a daemon 
(ipallocd) that generates an address and then matches it against those listed in the hosts 
and ipalloc. netrange maps. The ipallocd daemon also matches generated addresses 
against its own internal cache of current IP address client requests on the network. 

Request Boot File Download - This is the standard request that a diskless client issues when¬ 
ever it is booted. The PROM sends a tf tp request to boot from the file ip__address.s 3 86 on 
the boot server. 

Respond with Boot File ~ Because the file ip_address.s386 does not exist, the boot server 
will respond with a special boot file, /tf tpboot/pnp. s386. 

Ask To Be Configured - The program pnp. s 3 8 6 sends an RPC request for the system to be 
configured. 

Configure System - The pnpd daemon on the boot server issues the setup request on behalf 
of the new diskless client. 

ADocate Name - The system name is chosen from a pool of available names in 

pnp. sysnames(5). Next, the Ethernet address and name are added to the ethers map. 

(continued) 
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Adding a Diskless Client Through ASI (cont’d) 

Set Up System Directories - System files for a diskless client are stored in various subdirec¬ 
tories under /export on the boot server. These directories are added to the diskless client’s 
/etc/exports file. Also added to the client’s /etc/exports and /etc/f stab files are 
/usr, /usr/cluster (if applicable), and /usr/local. 

Note that the entries in /export are symbolic links to directories in other locations, as deter¬ 
mined by entries in /etc/where. See page 116 for details. 

As part of these steps, the standard files set up in /export/root/system/etc are: 

♦ net.conf 

♦ localtime 

♦ passwd 

♦ group 

♦ syslog.conf 

♦ sendmail.cf. 

The net. conf file is updated with information gathered during configuration, and the root 
password (the encrypted host id) is written to the passwd file at this time. 

Update YP Maps - Entries for the new system are added to the listed files. The same daemon 
that updates these files (rpc. ypupdated) then remakes YP, distributing the new maps to all 
slave servers. 

Export File Systems - The new directories set up in /etc/exports are exported so as to be 
available to the diskless client. 

Set Up tf tpboot Link - Sets up the link to the appropriate boot file for this SunOS version 
and architecture. 

Setup Complete - The system is now fully installed. The program pnp. s 3 86 reboots the 
system now that the proper files are set up on the server to allow a normal diskless boot. 
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What Happens When You Add a Diskless Client via ASI 
(This diagram is identical to the one presented on page 145.) 
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Adding a User through SNAP 

The process of adding a user involves three systems: 

♦ The master server, from which maps are read and updated 

♦ The group’s home directory server, which stores default files that will be copied to the new 
user’s home directory 

♦ The new user’s home directory server, where the user’s home directory will be set up 


Wiial SNAP Does 


SNAP performs the following procedures when you create a new user account. The headings 
below match those from the diagram. 

Read YP Maps - As soon as you select the Users category, SNAP reads the YP maps for the 
various files listed in the diagram. Files in parentheses () are read but will not be rewritten. 

</ Note that SNAP can read fQes from any YP server (including slave servers). As of 4.0.2, 
it no longer tries to bind to the YP master. 

Allocate UID - New UIDs are assigned automatically by a daemon (uid_allocd) that gener¬ 
ates a user ID and then matches it against those listed in the passwd. byuid map. The 
uid allocd daemon also matches this generated UID against its own internal cache of other 
current UID allocations on the network. 

Set Up Group Directories - Although users know their home directories as 
/home/usemame, home directories are physically organized by user group. For instance, 
the home directory for mtravis in the group users, is stored on mtravis’ home directory 
server as /f iles/home/users/mtravis. 

The user agent daemon (rpc. user_agentd) creates the appropriate group directory if it 
does not yet exist on the user’s home directory server. Note that tWs group directory is 
fiequently empty (except for containing home directories), and exists solely for 
organizational purposes. A group account’s tme home directory—where group default files 
are stored—^may be on an entirely different system. 

Set Up Home Directory - The home directory is set up on the workstation you designate as 
the “home directory server” for this user. The user agent daemon creates the user’s home di¬ 
rectory and then sets up a symbolic link so that it can be exported via /export. See “Inside 
the Sun386i File System” at the beginning of this chapter, for more information about export¬ 
ing conventions. 

Also in this step, default files and directories for a new user are copied from the directory 
/home/group/def aults (/files/home/group/group/defaults on the group’s home di¬ 
rectory server). You can set up custom environments for new users by editing these files or 
adding new ones. (If you want the system to perform additional setup tasks during new account 
creation, add instmctions to the copy_home script in /home/group.) 

Update YP Maps - These files are completely rewritten, with additional entries now included 
for the new user. The same daemon that updates these files (rpc. ypbatchupd) then remakes 
YP, distributing the new maps to all slave servers. 

Set Permissions - The user agent daemon sets appropriate directory permissions for the 
new user. 

(continued) 
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What Happens When You Add a User via SNAP 


What You Do 
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Adding a User Through SNAP (cont’d) 

Export Home Directory - The user agent daemon exports the home directory so that it will 
be available to all systems in the domain. Once exported, this directory is accessible on the 
network as /home/useraame via the automounter. 

Setup Complete - SNAP rereads YP maps and is ready for the next operation. As soon as 
SNAP redisplays its screen, the user account has been set up. 

^ Secure RPC - In Sun386i SunOS 4.0.2, SNAP no longer sets up entries for users in 
/etc/publickey. Creating and changing passwords in SNAP now works just like the 
passwd(l) command. SNAP still maintains publlckey information for existing ac¬ 
counts that have public keys. 

You can add publickey entries for new users with the chkey(l) command. 

man page for copy_home - Sun386i SunOS 4.0 and 4.0.1 do not have a man page for 
copy_home. SunOS 4.0.2 does include a man page on this script 

Additional Notes about SNAP and Users 

The following procedures use a variation of the steps performed when SNAP adds a user. Be¬ 
cause all the same files are involved, separate diagrams and descriptions are not included: 

♦ Changing a user’s primary group - YP maps are updated and the user’s home directory 
is moved on the home directory server (from /f iles/home/oldgroup/user to 

/f iles/home/newgroup/user). The symbolic links for the user in /export/home are 
also changed appropriately and the automounter’s auto. home map is updated with the new 
home directory path. 

^ In Sun386i SunOS 4.0.1, the auto. home map was not properly updated if you changed a 
user’s group via SNAP, and users would see the following message upon logging in: 

No Directory! Logging in with home=/ 

See page 36 of the Sun386i SunOS 4.0.1 Owner’s Bulletin for a workaround. Sun386i 
SunOS 4.0.2 supports any combination of simultaneous changes to user name, primary 
group, or home directory server. 

♦ Changing a user name - Home directory is moved from 

/f iles/home/group/oldusemame to /f iles/home/group/newusemame. 

♦ Changing the'home directory server - Home directoiy is moved to new system. 

♦ Removing a user - All YP maps set up when the user is added are updated accordingly. Us¬ 
er files are removed from the home directory server. Additionally, any publickey entry is 
removed. 

The manual counterparts to these procedures are covered in Sun386i Advanced 
Administration. 
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What You Do 
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Adding a User via New User Accounts 

The process of adding a user through the New User Accounts process involves two systems: 

♦ The master server, from which maps are read and updated, and where the default group 
directory (for the group users) normally resides 

♦ The user’s machine, which will become his or her home directory server 


Whal New User Accounts Docs 


The New User Accounts facility performs the following procedures when you create a new user 
account The headings below match those from the diagram. 

Standard Boot Sequence - The system runs its standard boot sequence, reading 
/etc/net. conf, probing the network for configuration information, and executing the com¬ 
mands in /etc/rc. boot, /etc/rc, and /etc/rc. local. 

As part of booting, init(8) reads /etc/ttytab(5), which contains a special getty(8) line 
for the console: 

console "/^sr/etc/getty -n -s -1 std.9600" sun on secure 

The -n flag instructs getty to bring up logintool(8) (and the New User Accounts screens) 
in lieu of running login(8). 

Allocate UID - New UIDs are assigned automatically by a daemon (uid_allocd) that gener¬ 
ates a user ID and then matches it against those listed in the passwd. byuid map. The 
uid allocd daemon also matches this generated UID against its own internal cache of other 
current UID allocations on the network. 

Set Up Group Directories - The user agent daemon (rpc. user_agentd) creates the 
appropriate group directory if it does not yet exist on the system (or on the bootserver, if it’s a 
diskless machine). Note that this group directory is frequently empty (except for containing 
home directories), and exists solely for organizational purposes. A group account’s true home 
directory—where group default files are stored—^may be on an entirely different system. 

Set Up Home Directory - Because the user is being added through the New User Accounts 
feature, the user agent daemon places the home directory on the machine from which the user 
logs in (or on the boot server for that machine, if the new user logs in to a diskless system). 

Also in this step, default files and directories for a new user are copied from the 
/home/users/defaults directory. You can set up custom environments for new users by 
editing these files or adding new ones. 

If you want the system to perform additional setup tasks during new account creation, add in¬ 
structions to the copy__home script in /home/users. 

Update YP Maps - These files are completely rewritten, with additional entries now included 
for the new user. The same daemon that updates these files (rpc. ypbatchupd) then remakes 
YP, distributing the new maps to all slave servers. 

Set Permissions - The user agent daemon sets appropriate directory permissions for the 
new user. 

Export Home Directory - The user agent daemon exports the home directory so that it will 
be available to all systems in the domain. Once exported, this directory is accessible on the 
network as /home/usemame via the automounter. 

Setup Complete - Control returns to getty(8) which runs login -n to complete the login 
process. 

^ man page for copy__home - Sun386i SunOS 4.0 and 4.0.1 do not have a man page for 
copy_Irome. SunOS 4.0.2 does include a man page on this script. 
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What You Do 
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Adding a Group Through SNAP 

The process of adding a group involves two systems: 

♦ The master server, from which maps are read and updated 

♦ The group’s home directory server, which stores setup files for new users who will be in this 
group 

Groups are treated much as users are: A yppasswd entry and home directory are set up for 
each new group you create. Each group name also serves as a mail alias by which you can 
address the users who belong to it. 


WiKil SNAP Docs 


SNAP performs the following procedures when you create a new group account. The headings 
below match those from the diagram. 

Read YP Maps - As soon as you select the Groups category, SNAP reads the YP maps for the 
various files listed in the diagram. Files in parentheses () are read but will not be rewritten. 

^ Note that SNAP can read files from any YP server (including slave servers). As of 
4.0.2, it no longer tries to bind to the YP master. 

Allocate UID - Because each group is treated as a user, a new user ID must be assigned. New 
UIDs are allocated automatically by a daemon (uid_allocd) that generates a user ID and 
then matches it against those listed in the passwd. byuid map. The uid_allocd daemon al¬ 
so matches this generated UID against its own internal cache of other current UID allocations 
on the network. 

Allocate GID - A unique group ID is assigned by the gid_allocd daetiKrn. This procedure is 
similar to what happens for UID allocation. 

Set Up Group Directories - The user agent daemon (rpc. user_agentd) creates the 
appropriate group directory on the group’s home directory server. 

Set Up Home Directory - Each user group has a home directory containing default files. 
Although the directory for the default group (users) is normally stored on the master server, 
additional groups can keep their directories anywhere. (The users group can also be moved 
to a different server, if desired, via SNAP.) 

The home directory is set up on the workstation you designate as the “home directory server” 
for this group. The user agent daemon creates the user’s home directory and then sets up a 
symbolic link so that it can be exported via /export. See “Inside the Sun386i File System” at 
the beginning of this chapter, for more information about exporting conventions. 

Also in this step, default files and directories for a new group are copied from the 
/home/users/defaults directory to /f iles/home/group/group/def aults. You can 
set up custom environments for new users in the group by editing these group default files or 
addiiig new ones. If you want the system to perform additional setup tasks during new account 
creation, add insfructions to the copy_home script in /files/home/group/group. 

Update YP Maps - These files are completely rewritten, with additional entries now included 
for the new group. The same daemon that updates these files (rpc. ypbatchupd) then re¬ 
makes YP, distributing the new maps to all slave servers. 

Set Permissions - The user agent daemon sets appropriate directory permissions for the 
new group. 
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Export Home Directory - The user agent daemon exports the group’s home directory so 
that it will be available to all systems in the domain. Once exported, the automounter makes 
this accessible on the network as /home/groupname. 

Setup Complete - SNAP rereads YP maps and is ready for the next operation. As soon as 
SNAP redisplays its screen, the group account has been set up. 

^ man page for copy_home - Sun386i SunOS 4.0 and 4.0.1 do not have a man page for 
copy_home. SunOS 4.0.2 does include a man page on this script. 


Adding a Printer Through SNAP 

The process of adding a printer involves two systems: 

♦ The master server, from which maps are read and updated 

♦ The print server—^the system with the printer 


What SNAP Docs 


SNAP performs the following procedures when you add a printer. The headings below match 
those from the diagram. 

Build Port List - SNAP builds a list of the parallel ports (/dev/ppn) and serial ports 
(/dev/ttyn) that exist on the local system. 

Get Valid Printers - SNAP reads a list of existing printers from the ypprintcap and 
ext_ports maps, and filters out all entries from ext_ports not associated with the local 
system. 

^ Note that SNAP can read files from any YP server (including slave servers). As of 4.0.2, 
it no longer tries to bind to the YP master. 

Allocate Printer Name - SNAP allocates a unique printer name by generating Ip names (Ip, 
Ipl, lp2,. . .) until it finds one that does not exist in ypprintcap. This name will appear in 
SNAP as the default name for the new printer. 

Make Spool Directory - Creates the /var/spool/printer directory to hold waiting print 
jobs. 

Update YP - The maps are rewritten with updated information. Printcap maps now contain 
the name and location of the new printer, and the ext__ports map now knows that this port 
on the print server is used for printing. 

Setup Complete - SNAP rereads YP files and is ready for the next operation. You can begin 
using the printer from any Sun386i system on the network as soon as SNAP redisplays its 
screen. 

A Note on Local Spool Directories 

It is not necessary to create spool directories on other Sun386i machines, because Ipr and 
Ipq create local spool directories as needed. However, if you plan to use this printer from 
Sun-3, Sun-4, or SPARCstation systems, you’ll need to create local spool directories (as 
/var/spool/printer) on those systems. 
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What Happens When You Add a Printer Using SNAP 
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Adding a Terminal Through SNAP 

The process of adding a terminal involves two systems; 

♦ The master server, from which the ext_ports map is read and updated 

♦ The system with the terminal 


Whcll SNAP Docs 


SNAP performs the following procedures when you add a terminal. The headings below match 
those from the diagram. 

Build Port Table - SNAP builds a list of the serial ports (/dev/ttyn) that exist on the local 
system. 

Get Valid Port List - SNAP reads a list from the ext_ports map of existing ports and their 
current assigned uses. It also filters out all entries from ext_ports that are not associated with 
the local system. 

Set Port Permissions - When you enable the terminal, SNAP sets the port permissions to 
622 so that only the getty daemon can open it. This prevents other applications (such as 
DOS) from accessing the serial port until it is disabled. When you disable or remove the port, 
SNAP sets the permissions back to 666 so that anyone can read or write to the port 

^ In Sun386i 4.0.2, permissions are reset to 666 when you disable or remove the terminal in 
SNAP (a bug in Sun386i 4.0.1 prevented this). 

Modify ttytab - Add the getty(8) and terminal type information to the appropriate line in 
/etc/tty t ab(5). 

Modify ext_ports - Note the current use of this port in /etc/ext_ports, and rebuild YP. 

Enable Soft Carrier - Instrwt the kernel to ignore the carrier detect line. 

Background; For a modem, SunOS systems use a mode called “hard carrier detect,” which 
basically waits for the serial port’s carrier detect line to be asserted before opening the port for 
use. Because terminals do not need to wait for a carrier, they can ignore this serial line. On 
Sun386i systems, “soft carrier” mode is set for terminals so that the port is opened regardless 
of the carrier line’s current state. 

Setting this soft carrier mode has the same effect as the traditional procedure of disabling 
carrier detect in the kernel and then rebuilding it. SNAP sets soft carrier mode through an I/O 
control. Users can do the same thing manually by issuing the following command; 

system: SUPERUSER:!} /usr/etc/ttysoftcar -y devicename 

Start getty Daemon - SNAP sends a signal to init so that it rereads /etc/ttytab and 
starts the getty daemon running on the specified port. 

Setup Complete - SNAP rereads YP files and is ready for the next operation. You can begin 
using the terminal as soon as SNAP redisplays its screen. 
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Adding a Modem via SNAP 

The process of adding a modem involves two systems: 

♦ The master server, from which the ext_ports map is read and updated 

♦ The system with the modem 


WiKil SNAP Docs 


SNAP perfonns the following procedures when you add a modem. The headings below match 
those from the diagram. 

Build Port Table - SNAP builds a list of the serial ports (/dev/ttyn) that exist on the local 
system. 

Get Valid Port List - SNAP reads a list from the ext_ports map of existing ports and their 
current assigned uses. It also filters out all entries from ext jports that are not associated with 
the local system. 

Set Port Permissions - When you enable the modem for either dial-in or dial-out, SNAP 
sets the port permissions to 622 so that only the getty daemon can open the port. Ibis pre¬ 
vents other applications (such as DOS) from accessing the serial port until it is disabled. When 
you disable the modem for both dial-in and dial-out, SNAP sets toe permissions back to 666 so 
that anyone can read or write to toe port. 

^ In Sun386i 4.0.2, permissions are reset to 666 when you disable or remove toe modem in 
SNAP (a bug in Sun386i 4.0.1 prevented this). 

Set Up Dialer - SNAP creates an alternate device for toe modem using mknod. The device 
name begins with cu and corresponds to toe port ID (letter/number) of toe serial device to 
which toe modem is attached. Examples; 

/dev/cua for /dev/ttya 

/dev/cumO for /dev/ttymO 

/dev/cuml for /dev/ttyml 

Permissions on toe /dev/cuportID device are set at 600 for dial-out or dial-in/dial-out and 
000 for dial-in-only (no toal-out) modems. 

Modify Local Files - Update /etc/ttytab and /etc/remote with the appropriate modem 
entries. 

Modify ext_ports - Record toe current use of this port in /etc/ext_ports, and rebuild 
YP. 

Disable Soft Carrier - Insfruct toe kernel to acknowledge toe carrier detect line. 

Background: For a modem, SunOS systems use a mode called “hard carrier detect,” which 
basically waits for a serial port’s carrier detect line to be asserted before opening toe port for 
use. The “soft carrier” mode, normally set for terminals, must therefore be disabled when 
you’re using a modem on Sun386i systems. 

Disabling this soft carrier mode has the same effect as toe traditional procedure of enabling 
carrier detect in the kernel and then rebuilding it SNAP controls soft carrier mode through an 
I/O control. Users can do toe same thing manually by issuing toe command: 
/usr/etc/ttysoftcar -n devicename. See Chapter 1 for further information. 

Start getty Daemon - SNAP sends a signal to init so that it rereads /etc/ttytab and 
starts toe getty daemon mnning on toe specified port. 

Setup Complete - SNAP r^eads YP files and is ready for toe next operation. You can begin 
using toe modem as soon as SNAP redisplays its screen. 
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Backing Up Data Through SNAP 

SNAP backups can involve several systems on the network: 

♦ The local sy stem that will perform the backup 

♦ Your home directory server, where a catalog of backup information is stored 

♦ The file servers containing the files you plan to back up 

Backing up files is actually a two part process. In Part A, you schedule the backup via SNAP. In 
Part B, shown on the pages following, cron starts a job at the appointed time to perform the 
backup. 


Part A - What SNAP Does 


Build Table of Backups - All backups on a machine—scheduled or unscheduled—are 
recorded in roofs crontab(5) file. Each backup has its own ID which is used to determine file 
permissions and to access backup catalog files and maps. 

SNAP examines the unique backup IDs, backup names, and other flags for each backup line in 
roofs crontab file. SNAP translates this information into the backup list you see in the 
bottom SNAP panel. 

Start Organizer - If you ask to back up selected files, SNAP starts a special version of 
Organizer. You use this Organizer window to choose the files to back up. 

Write Backup List - When you choose the Backup button in Organizer, it writes a list of se¬ 
lected files to /var/spool/backup/BACKUP_unique_id. A typical name for the file list 
might be: 

BACKUP_425776879_822089534 

The program /usr/etc/backup will pass this file list to bar in a later step. 

Update root crontab - As soon as you choose Sched to schedule the backup, SNAP sets up 
this backup in roofs crontab. If you’ve asked to be reminded before the backup, SNAP will al¬ 
so create a separate crontab line to remind you of the backup via the console window, mail, 
or both. 

Finally, SNAP writes to the named pipe /var/spool/cron/FlFO to alert cron(8) to the new 
jobs pending. 

Setup Complete - SNAP rereads the root crontab file and is ready for the next operation. 
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; Part A - What SNAP Does 


Your System 


Read root crontab file and extract all 
backup lines 

Examine flags to determine ownership and 
whether backup is scheduled 


Start a special version of Organizer 


Write the list of selected files to 

/var/spool/backup/BACKUP_t/n/qye_/af 


Write backup information to 

/var/spool/cron/crontab/root 

Schedule reminder in this same crontab 
file 

Write to named pipe in /var/spool/cron 
to schedule new cron jobs 


Your Home Directory Server 


Setup Complete 
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Pai1 B - What cron Docs 


The program /usr/etc/backup is responsible for both initiating backups and for 
reminding you about backups that are scheduled to take place. 

Send Reminder - If yon have asked to be reminded about the backup, cron executes a line 
such as the following, and you will receive notice of the backup via the console window, mail, 
or both: 

00 16 * * * /usr/etc/backup T BACKUP_425776879_822089534 "My Backup" Full /dev/rfdOa Full Both Once mtravis 5075 0 

Start Backup - A separate crontab line initiates the backup at the appointed time: 

00 23 * ’ * /usr/etc/backup B BACKUP_425776879_822089534 "My Backup" Full /dev/rfdOa Full Both Once mtravis 5075 0 

The /usr/etc/backup program reads the appropriate files in /var/spool/backup (the 
file is named baCKUP_425776879_822089534 in this example) and builds a list of files and 
directories to be backed up. It then passes this list to bar, which performs the actual backups. 

Done - When the backup is done, remove the tape and label it. 
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What Yog Do 







Insert tape or diskette 


Wait for backup 


4^ Insert media as needed 


(6J Remove tape or diskette 
I and label it 


What Happens When You Use SNAP Backup (cont’d) 


Part B - What cron Does 


Your System 


Mail or display backup reminder 


Start /usr/etc/backup at the appointed 
time __ 

j Write to backup catalog 
Back up files via bar 

Mail or display backup completion message 


Your Home Directory Server 


~/.backup/Sacki/p_cafa/ogr 
(— 

“1 -/.backup/Bac/fup_^/e_/nap 

Lj 

^l.badmplBackup_device_map 
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What’s in the crontab Entry 

Here is a typical crontab line as written by SNAP Backup: 


00 16 * * * /usr/etc/backup T BACKUP_42S776879_822089534 "My Backup" Full /dev/rfdOa Full Screen Once mtravis 5075 0 


\ 


/ 


backup command 

cron time entries Backup flag 


\ 


File list 


\ 

How often? 


Backup description Device Notification method User name and ID 





cron time entries - Standard cron time settings. See crontab(l) or Sun386i Advanced 
Skills for details. 

backup command - This command starts backups, notifies you of pending backups or errors, 
and keeps logs of backups performed. 

Backup flag - Valid entries are: B for a scheduled backup, xB for an unscheduled backup, R 
for a mnning backup, x for a backup reminder, and xX for an unscheduled backup reminder. 

File list - The name of the file in /var/spool/backup that contains a list of the files to back 
up. 

Notification method - You have the choice in SNAP of Screen, Mail, or Both. 

Files flag - Indicates what files are to be backed up: 0 is for all home directory files, 1 is for 
specific home directory files, 2 is for all files on the local system, 3 is for specific files on the 
local system, 4 is for all files on the network, and 5 is for specific network files. 

Backup description. Type, Device, How often?. User name and ID - Additional 
information used when backing up files or notifying you about backups. 

Options used by /usr/etc/backup 

The bar command options used by /usr/etc/backup when backing up files are as follows: 

f - followed by device name, /dev/rst8 or /dev/rf dOa 

V - for verbose output, used to create the backup catalog 

K - to follow directory symbolic links specified on the command line 

H - followed by the backup description; this is used in the bar volume header 

I - followed by the name of the file in /var/spool/backup that contains the list of files to be 
backed up 

z - to have bar congress files when archiving 

u - followed by the user ID of the user that specified the backup; this is used in the bar volume 
header 

M - if the backup is to be incremental, followed by the cut-off date for the backup 
D - followed by the date and time of the backup; this is used in the bar header 
N - to force bar to check the ownership of the media before writing 


166 


Chapter 9 - Under The Hood 



Sun386iAdministraHm Cookbook 


Continuing a Backup 

If bar requires an additional tape or diskette, a child process of /usr/etc/backup sends a 
message to you via mail or the console window. When you insert a new tape or diskette and 
then choose Continue in SNAP, SNAP sends a signal to this child process, and the child in¬ 
stincts bar to continue backing up onto the next volume. 

Backup and the operator Group 

A member of the operator group is given the following privileges; 

♦ root file access in Organizer when selecting files for backup or restore 

♦ Option of backing up all system or all network files 

♦ Ability to unscbedule or remove another user’s backup profiles 

♦ Ability to restore files from another user’s backup 
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Restoring Data through SNAP 

SNAP Restore can involve two or more systems on the network: 

♦ Your home directory server, where a catalog of backup information is stored 

♦ The file servers on which you will restore your data 


Wliiil SNAP Docs 


SNAP performs the following procedures when restoring fOes. The headings below match 
those from the diagram. 

Start Organizer - SNAP starts a special version of Organizer that you use to choose the files to 
be restored. To build the file list, Organizer reads the backup catalog in your home directory. 

If this catalog does not exist, you can recreate it from the backup tape or diskette using the 
Add Entry button in SNAP. (Note that if you choose Restore All, SNAP Restore does not 
read the backup catalog fOes.) 

If you have previously selected files to restore fiom this backup. Organizer reads this list of 
selected files from /var/spool/backup/RESTORE_uniqueID and highlights those files. 

Build Restore List - SNAP builds a temporary list of files to be restored in 
/var/spool/backup. 

Restore Files - SNAP starts bar, which uses the following options to restore from the backup: 
f - followed by device name, /dev/rstS or /dev/rf dOa 
V - for verbose output 

I - followed by the name of the file in /var/spool/backup that contains the list of files to be 
restored 

z - to have bar uncompress files when extracting 

T - to stop when the first occurrence of every file is found 

S - to restore files to a new directory, if specified 

s, D, G - to restore files to a new user, if so specified 

O - to check the media for ownership, if not in the operator group 

Done - Restoration of the backup is conqjlete. 
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What Happens When You Use SNAP Restore 


What You Do 


I Choose Restore in 
Organizer window 

I Choose Done in 
Organizer window 


Move back to 
SNAI^ window 


i Choose Begiim to begin 
restoring 



Insert tape or diskette 


M 3 ^Insert media as needed 


i What SNAP Does 


Start SNAP 
from your system 


@ Select Restoire 
category 

I Choose Select Files 

Select files in 
Organizer 



Your System 


Your Home Directory Server 


Start a special version of Organizer 

Read the catalog for this backup 

Read the list of selected files from 
/var/spool/backup/R EST OR E_uniquelD, 
if such a list exists. 


Create a list of files to restore in 
/var/spool/backup/RESTORE_un/que/D 


1 backup/Backup_catalog 

If — 

backup/Backup_file_map 
^ backup/Backup_device_map 


SNAP displays the number of the tape 
or diskette to insert 


Restore Files 


Restore selected files using bar 


Done 
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Booting a Network Qient 

The boot procedure on a Sun386i is different than on other Sun workstations in the following 
ways: 

♦ Sun386i workstations normally display a minimum amount of information when they boot. 
Other Sun workstations display more information that is meaningful to SunOS experts but 
not to most users. However, you can have the additional information displayed on a 
Sun386i system by changing an NVRAM value. (See Chapter 4 for details.) 

♦ Sun386i network clients, diskless clients, or diskful clients automatically get the information 
necessary for installation and booting from the network. For other Sun workstations, the in¬ 
formation must be resident on the system and must be manually configured at installation. 

♦ Sun386i workstations store network confrguration information in a file (/etc/net. conf) 
that is unique to Sun386i systems. Other Sun workstations store the information in several 
files. 

♦ A Sun386i workstation has identical run command files (/etc/rc, /etc/rc. boot, and 

/etc/rc. local) regardless of its role on the network. For other Sun workstations, the con¬ 
tents of these files must be modified based on the system’s network role. 

The headings below match those from the diagram. 

Start standard boot sequence - The Sun386i network client begins by following the standard 
boot sequence used on all Sun systems: It starts with boot(8S), which starts init(8S), which 
starts a shell to execute /etc/rc. boot. The rc. boot(5) script begins by performing a file 
system check, just as on other Sun systems. Once the file systems have been checked, 
rc. boot proceeds to examine the system’s /etc/net. conf file (next step). 

Execute /etc/net. conf - The net. conf file contains some basic information about the 
system. Here is an example of a net. conf file: 

HOSTNAME=hostname 

DOMAlNNAME=YP.noname.com 

NETWORKED=yes 

PNP=yes 

VERBOSE=no 

When this file is executed, each variable and its setting is read into memory. Note that some of 
these variables may be reset in later steps. 

Configuration probing on? - The setting for pnp determines whether the system will do con¬ 
figuration probing (next step). If configuration probing is enabled (PNP=yes), the system will 
probe the network for configuration information in later steps, and may reset some of the vari¬ 
ables in /etc/net. conf. If configuration probing is disabled (PNP=no) then the system will 
use the /etc/net. conf settings as is. 

Run netconf Ig - The program /sbin/netconf ig is started from rc. boot. 

If PNP=yes, then rc. boot rans netconf ig -e, which checks the HOSTNAME and 
DOMAINNAME variables against the ypservers map to see if this is a master or slave server. If 
the system is not a server, netconf ig commences with its IP address and configuration 
requests. 

If PNP=no, the system mns netconf ig -ne. The -n option skips configuration probing. 

Is Network Connected? - netconf ig probes to see if the system is connected to the 
network. 
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Get IP address (Done only if configuration probing is enabled) - The program 
/sbin/netconf ig, started from /etc/rc. boot, broadcasts a Dynamic RARP (DRARP) 
request for the IP address of this system. 

Look up client (Done only if configuration probing is enabled) - The first server (master or 
slave) to answer the RARP request becomes the temporary boot server that will provide the IP 
address to the new client. 

The rarpd daemon running on the boot server uses the client’s Ethernet address as a key to 
look up the system’s assigned IP address. The daemon first matches the Ethernet address with 
an entry in the YP ethers map to determine the client’s host name. The daemon then uses 
this host name to look up the client’s IP address in the YP hosts map. 

The IP address is then returned to the client. 

Probe for configuration info (Done only if configuration probing is enabled) - Once the 
netconf ig program knows the IP address, it sends out an RPC request for additional configu¬ 
ration information, such as the name of the domain and the host name. Again, the first server 
to answer becomes the temporary boot server that manages the configuration information. 

Return configuration info (Done only if configuration probing is enabled) - The pnpd dae¬ 
mon on the boot server looks up conf^iguration information in the YP maps, and passes it back 
to netconf ig on the client system. 

Check message mode (Done only if configuration probing is enabled) - netconf ig 
checks the value at NVRAM location 494. If the value at this location is 0, netconf ig disables 
explicit boot messages by setting VERBOSE=no. If the value at location 494 is 1 or 2, 
netconf ig sets VERBOSE=yes. 

Assign settings - If configuration probing is enabled, then netconf ig sets the host name, 
domain name, time zone, and IP address. 

If configuration probing is disabled, netconf ig sets the host name and domain name 
(based on the original values set from /etc/net. conf ), but it does not set the time zone or 
IP address. The system’s IP address is instead determined from its local /etc/hosts file. 

Set up Network Interface (Done only if configuration probing is disabled) - rc. boot runs 
i f conf ig(8c) to configure network interface parameters. 

Rewrite /etc/net . conf (Done only if configuration probing is enabled) - All variables are 
rewritten to the /etc/net. conf file. Some of these values may have been changed during 
configuration probing. 

Re-execute /etc/net. conf - rc. boot executes this file again so that any new variable set¬ 
tings take effect. Although this step is not strictly necessary in cases where PNP=no, re-execut- 
ing the file simplifies the rc. boot script. 

Continue booting - The system finishes mnning rc. boot, and then runs rc and 
rc. local. 

Reference: Chapter 5 of this manual (“Sun386i Probing” section) 

Chapter 10 of this manual (net. conf description) 

Sun386i Advanced Administration, (February 1989 edition. Chapter 1) 

On-line Sun386i SunOS 4.0.2 man pages (man_pages optional cluster must be 
loaded) — netconf ig (8S), rc. boot (8S) 
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What Happens When You Boot a Network Client 
(This diagram is identical to the one presented on page 171.) 
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Sun386i Backups 


Sun386/ Backup Hints 


The Problem Defined 


Hint 1: Check File Size 



HINTS AND TIPS 


-—-. 

^^ ^ 


Customers may find that regularly scheduled backups which used to take fi’om 15 
minutes to two hours when mnning Sun386/ SunOS 4.0.1 may now take 
increasing amounts to time after upgrading to Sim386/ SunOS 4.0.2. This article 
contains the problem definition and two hints to reduce time needed for backups. 

SNAP backup writes the list of files backed up to the backup catalog, which 
resides in the . backup subdirectory of the user’s home directory. The backup 
catalog is composed of the three files listed below. 

Backup_device_map 

maps device names to unique IDs ^ 

Backup_file_map 

maps filenames to unique IDs 

Backup_catalog 

contains the backup info (fileid, date, time, description, deviceid, and 
volume number) 

The backup catalog is used when you press the [SELECT FILES] button in 
SNAP’s restore category. A mini-organizer displays the backup catalog and 
allows you to selectively chose files to restore. 

Because the backup catalog is composed of simple ASCII files, searches and 
sorts of those files will take longer as the files grow. 

You should check the size of the above listed files, and purge entries by date 
using the [REMOVE ENTRY 1 button in SNAP’s restore category. Note that 
[ REMOVE ENTRY 1 changes the ownership of the backup catalog files to root so 
you will have to use chown(l) after doing the remove entry. 
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Hint 2: Remove Entries 
Manually 


Alternately, you can remove every entry in the above listed files manually. After 
doing this you will no longer be able to selectively chose files to restore through 
[ SELECT FILES 1 in SNAP’s restore category. 

Individual files can be restored using bar as shown below. 

% bar xvfZp /d&v/rfdOa.filel file2 ... I* for floppy*! 

% bar xvfZp /dev/rst8 fllelfllel... i* for tape *1 

RESTORE ALL 1 in SNAP’s restore category does not use the backup 
catalog. 

Fixing the bug in Sun386/ SimOS 4.0.1 that caused the backup catalog to get 
corrupted now causes SNAP backups to take longer in Sun386/ SunOS 4.0.2 
because the backups write to the baclmp catalog more often during the backup. 

Keeping the size of the catalog small should help with the backup performance. 
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DOS Memory Tips 



DOS Memory Usage Shooting This article contains DOS memory usage tips for those running Sun386/ SunOS 
Tips 4.0.1 or 4.0.2 on Sun386/ workstations.^ 

Tip 1: Determining Available Not all applications know how to use the expanded memory driver. Some 

Memory applications can use the expanded memory driver but do not auto-detect its 

presence. These applications may require a different configuration or switch 
settings or both when started. 

You can determine how much memory is available for a application in the DOS 
window by using the chkdsk c: command. This will report the amount of 
free memory as shown in the below example. The example shows there are 
‘546144 bytes free’. 

D:\HOME\EDEAN\DOSAPPS>chkdsk c: 

21309440 bytes total disk space 
55296 bytes in 2 hidden files 
12288 bytes in 6 directories 
2580480 bytes in 166 user files 
18661376 bytes available on disk 

655360 bytes total memory 
546144 bytes free 

D:\HOME\EDEAN\DOSAPPS> 

The Sun386/ DOS window uses more memory for resident drivers than most PCs 
due to the amount of emulation that we need to load. A big difference can 
usually be found by removing the redirector which is uses about 50k of memory 
for Sun386/ SunOS 4.0.1, or about 25.9k for those running Sun386i SunOS 4.0.2. 

Of course by removing this option you would loose all networked drives. You 
can do a quick test by turning off the redirector by editing your 
C: autoexec. bat file by commenting-out the redirector entry, and then 
rebooting the DOS window. 

In order to address the problem correctly, you need to know just how much 
memory is available on the XT, AT, and on the Sun386/ using the 
chkdskcommand. Very often a DOS application can be configured to use less 
memory. 


^ The tips contained in this article are submitted by Ed Dean, Sun BOS Software, Boston Development 
Center. 
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Note that if you are comparing an application’s performance on an XT or AT to a 
Sun386i, remember that XTs and ATs do not have configurations similar to the 
default Sun386/ configuration. For example, most XT and AT machines do not 
have redirected drives installed. 

Tip 2: DOS Extenders If you find that an application is too large, and there is not a memory emulation 

problem, consider using a DOS extender, available from third-party vendors. 
One example is the QEMM386, runs in v86mode , and is available fi'om 
QuarterDeck.^ 

The extender provides the user with a transient program area close to the full 
640k by moving drivers, redirectors, and the like to expanded memory. For 
example, PC LAN software typically uses 50-70k, and you can load this into 
‘high memory’. 


^ Please note that this reference is not an endorsement of the example product named. Customers may wish 
to explore other DOS extenders as well. 
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THE HACKERS’ CORNER 


FreeSpace 



FreeSpace, the Final Frontier This month’s Hackers’ Corner contains FreeSpace, a tool to help you in your 

disk space, cost-saving voyages. It is an ongoing mission, to explore efficient 
new ways of cleaning up old files, too seek out ways of deleting them, to boldly 
delete where no one has deleted before....® 

The below tool was written to help find large, old files that are no longer needed, 
so you can delete them and free new frontiers of disk space. If each user deleted 
just one Mbyte of unneeded files, it would save your company unnecessary costs 
by postponing the need to add more disks. 

Please consult your local shell script or programming expert regarding any script 
or code problems. TTie example programs are not offered as a supported Sun 
product, but as items of interest to enthusiasts wanting to try out something for 
themselves. Note that Hackers’ Corner code may not work in all cases, and 
may not be compatible with future SunOS releases. 

Using the FreeSpace Tool Follow the steps listed below to use FreeSpace. 

1. Save the below code to a file named cldir . 

2. Enter the command chmod +x cldlz . 

3. Enter the command cldir . The sort selection menu will appear as 
shown below. 

4. Type h if you need help. The action options menu will appear as 
shown below. 


® This month’s Hackers’ Comer is submitted by Bill Petro, GSG Marketing, Mountain View, California, 
USA. 
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An Example Usage An example usage is shown next which specifies sorting files by size, followed 

by skipping over the largest file, selecting the help screen, and then quitting 
FreeSpace. 

Be Happy :-)cldir 
Sort Selection: 

a - Alpha, alphabetical 

A - All Alphabetical, including dot files 
p - Pattern, by pattern with wildcards 
r - Reverse date 
s - Size, largest first 
L Larger than, over xx bytes 
t - Time, oldest first 
T - Age, xx days ago 
q - Quit 

Enter letter of choice: s 
Sorting by size ... 

Use (n)ext, (l)ist, (p)rint, (d)elete, (q)uit, e(x)it, or (h)elp 
386i.index.awk: 42272 Aug 28 15:11 = ascii text : [nlpdqx]:n 

windows.detail: 39475 Sep 13 12:49 = [nt]roff, tbl, or eqn input te: [nlpdqx]:h 
Action options: 


n 

next 

1 or . 

more 

P 

print 

d or r 

deleting 

f 

Files in sort selection 

M 

mail 

: 

single csh command 

I 

new csh shell 

q 

quit this level 

X 

exit 

windows.detail: 
Exiting ... 

Be Happy :-) 

39475 Sep 13 12:49 = [ntjroff, tbl, or eqn input te: [nlpdqx] :q 

SunOS Revision Levels 

The below tool works for those running SunOS 4.x, since the /bin/find is 
used. For those running SunOS 3.x, you will need to change this command 
pathname to /usr/bin/f ind . 

The FreeSpace Tool 

The code for the FreeSpace tool appears on the following pages. 

For an online copy of the FreeSpace code, simply send email to sunistb-editor. 
Please specify that you want the November 1989 Hackers’ Corner code. 
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#! /bin/sh - 

# cldir “ present a list of sorted files for display, printing or deleting 

# 

# This tool is intended to be used to clean up a directory, including 

# it's subdirectories. It presents a list of files that the user 

# may then display, print, delete, examine with a mail program, etc. 

# The script can be easily modified to add other options at the users 

# discretion. The optional C program "grabchars”, written by Dan Smith 

# of Island Graphics, is available via anonymous ftp from Bill Petro for 

# users internal to Sun. "grabchars" gets one or more keystrokes from 

# the user, without requiring them to hit return. It was written to make 

# shell scripts more interactive and simulates ’’cbreak" features 

# available in other programs. 

# There are two levels to the cldir script, the sort selection level 

# [which can be done alternatively on the command line] and the 

# action level [which determines the action to be taken on a specific file]. 

# Files in a directory may be SORTED by: 

# a alphabetical order 

# A including "invisible" dot files 

# P pattern using wildcard characters 

# s by size, largest first 

# L by "larger-than", using the find command 

# t by date, oldest first 

# r by reverse date, youngest first 

# T by age, using the find older-than command 

# At the ACTION level, the user determines what to do with the file 

# displayed. The user may do nothing and: 

# n go on to the next file 

# 1,. list using the pager of the user's choice 

# [configurable in the pager variable] 

# p print 

# d delete 

# M examine by the mail program of choice, if it is a mail folder 

# [configurable in the mailer variable] 

# f show all filenames for the sort criterion 

# : execute a single shell command 

# ! create to a subshell in the current working directory 

# q quit this iteration of the program 

# X bail out and exit the program entirely 

# Comment in the following 3 lines if "grabchars" program is available 
grabchars() { 

read x; echo $x 

} 

cldir='basename $ 0' 

mailer="mail" # can be "mail", "Mail", "mush" 

pager=more # can be "more", "less", "cat" 

shell==csh # can be "sh", "csh", "ksh" 

shorthelp="Use (n)ext, (l)ist, (p)rint, (d)elete, (q)uit, e(x)it, or (h)elp" 
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longhelp=" 

Action options: 

n next 

1 or . $pager 

p print 

d or r deleting 

f Files in sort selection 

M $mailer 

: single $ shell coiranand 

\ new $shell shell 

q quit this level 

X exit" 

# >>>>>>>>>>>>>>>> Sort Selection Level <<<<<<<<<<<<<<<<<<<<< 
while [ $# -ge 0 ] 
do 

if [ $# != 0 ] 
then 

choice=$l 

fi 

case $choice in 

"a I a) style="alphabetical" 

kind="a 

echo "Sorting by $style ..." 
f iles= Vl>in/ls' 

f ) 

“A|A) style="All_alphabetical" 

]cind=-A 

echo;echo "Sorting by $style ..." 
f iles='/l^in/ls -a | egrep -v | "“XA-$ ' 

/ / 

-pIp) style="pattern" 

kind=-p 

echo; echo -n "Enter pattern (with wildcards): " 

read filepattern 

files=$filepattern 

echo;echo "Sorting by $style ..." 

/ f 

-s|s) style="size" 
kind=-s 

echo "Sorting by $style ..." 

files= Vl^in/ls -s | grep -v total | sort -r | colrm 1 5' 

t / 

-l|l) style="Larger_than" 
kind=-L 
echo 

echo -n "Enter over how many bytes (ex. 1000): " 
read chars 

echo;echo "Sorting by $style ..." 

files=Vbin/find . -type f -size +${chars}c -print' 

/ / 

-t|t) style="date" 
kind=-t 
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echo "Sorting by $style ..." 
files= Vbin/ls -tr' 

/ } 

-t|t) style="Age" 
kind=-T 
echo 

echo -n "Enter how many days ago (ex. 90): " 
read ago 

echo;echo "Sorting by $style ..." 

files=Vbin/find . -type f -atime +$ago -print ' 

t / 

-u|u) situation=''Unhelpful" 

ft 

-rIr) style="reverse_date" 

kind=-r 

echo;echo "Sorting by $style ..." 
files=Vbin/ls -t' 

/ t 

"■Q[|q[) echo;echo Exiting ...;exit ;; 

"") echo ' 

Sort Selection: 

a - Alpha, alphabetical 

A - All Alphabetical, including dot files 
p - Pattern, by pattern with wildcards 
r - Reverse date 
s - Size, largest first 
L - Larger than, over xx bytes 
t - Time, oldest first 
T - Age, XX days ago 
q - Quit' 

echo -n 'Enter letter of choice: ' 

choice='grabchars -b' 

echo 

continue ;; 

*) echo;echo "Usage: $0 -[aAprsLtT] " 
exit ;; 

esac 

if [ $# -ge 1 ] 
then 

shift 

fi 

if [ $# « 0 ] 
then 

break 

fi 

done 

echo 

# Only echo short help list the first time through, not in subdirectories, 
if [ "$situation" != "Unhelpful" ]; then 
echo $shorthelp; echo 
fi 
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# >>>>>>>>>>>>>>>> Develop Display <<<<<<<<<<<<<<<<<< 
for file in $files 

do 

if (test -f $file ); then 
while true 
do 

echo Vbin/ls -la $file' 'file $file' | \ 

awk '{desc_pos = index($0, $9) + length($9) + 1; \ 
desc = subst.r($0, desc_pos, 30); \ 

printf ("%-10s%9s %3s %2s %-6s= %-20s: [nlpdqx]:", \ 

$9, $4, $5, $6, $7, desc)}' - 

# >>>>>>>>>>>>>>>> Action Level <<<<<<<<<<<<<<<<<<<<< 

choice='grabchars -b' 

#echo " " #uncomment if using grabchars program 

case $choice in 
[n" "]) break ;; 

[1.]) $pager $file ;; 

p) echo "printing $file ...";lpr $file ;; 

[dr]) echo "deleting $file ...";rm $file; break ;; 

D) echo "del $file ...";mv $file $HOME/nukem/$file ; break ;; 
f) echo "Files in '$style'; ";echo $files | fmt -5 | $pager ;; 

F) echo "Files in '$style': ";/bin/ls -la $files | $pager;; 

h) echo "$longhelp" ;; 

M) $mailer -f $file ;; 

[Qq]) echo "Exiting ...";exit ;; 
t) echo "touch $file ..."/touch $file ;; 

[:";"]) echo ~n "Command: "/read cmd/csh -c "$cmd" // 

!) echo "spawning shell ..."/$shell // 
z) echo "compressing $file"/compress $file // 

[Xx]) echo "Bailing out ..."/exit 1 // 

*) echo $shorthelp // 
esac 
done 
else 

cd $file 

echo Descending directory: $file 
$cldir $kind -u 
if [ $? = 1 ]; then 
exit 1 
fi 

cd . . 

echo Now in 'pwd' 
fi 
done 
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Siin386r Ethernet Pins 



Sun386/Ethernet Compliance The Sun386i Configuration Guide, February 1989, indicates that Sun386/ 
and Pinouts machines are IEEE 802.3 compliant. However, the Sun386/ network interface is 

electrically Ethernet V2.0 on the built-in Ethernet connection.^ 

The differences between the DIX (Digital-Intel-Xerox) Version 2.0 Ethernet 
specification and the IEEE 802.3 specification should not affect the operation of 
the system or the network. 


Sun386/ Ethernet V2.0 Pinouts 


The schematic diagrams show the pinouts of the Ethernet interface on the 
Sun386/ backpanel to be as listed below. 


3 

10 

5 

12 

2 

9 

6 
13 

shell 


Data Out circuit A (Transmit +) 

Data Out circuit B (Transmit -) 

Data In circuit A (Receive +) 

Data In circuit B (Receive -) 

Control In circuit A (Collision Presence +) 
Control In circuit B (Collision Presence -) 
Voltage Common (Power Return) 

Voltage Plus (Power) 
ground/earth 


I, 4,7,8, No Connection 

II, 14,15 No Connection 


^ This article is submitted by Chuck Kollars, Marketing Support Engineering, Boston Development Center. 
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Siiii386i Serial Pins 



Sun386/ Serial Port Pinouts The pinouts for the Sun386/ serial port are shown in the below list, taken from 

the page COMM-2 in the Troubleshooting section of the Field Engineering 
Handbook - Technical, Volume 1, dated 5/89.® 

The connector is RS-232/RS-423, Port A, 25-pin D-Sub, Male. 


Pin 

Signal 

2 

TxD 

3 

RxD 

4 

RTS 

5 

CTS 

6 

DSR 

7 

GND 

8 

DCD 

15 

TxC 

17 

RxC 

20 

DTR 

22 

RI 

24 

TxCO 

25 

-5 vdc 


^ This short subject is submitted by Giuck Kollars, Marketing Support Engineering, Boston Development 
Center, USA. 
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Software Release Levels 



As of September 22,1989 
Operating Systems 


Product Name 

Current Release 

SunOS 

4.0.3 

SunOS SPARCstation 1 

4.0.3c 

SunOS 386/ 

4.0.2 
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Communications Products 


Product Name 

Current Release 

SunLink BSC3270 (SunOS 3.x) 

3.0 

SunLink BSC3270 (SunOS 4.x) 

6.1 

SunLink SCP 

6.0 

SunLink TEIOO 

6.0 

SunLink BSCRJE 

6.0 

SunLink Local 3270 

6.1 

SunLink SNA3270 

6.1 

SunLink Peer-to-Peer 

6.0 

SunLink IR 

6.0 

SunLink DDN 

5.0 

SunLink DNI 

6.0 

SunLink OSI 

6.0 

SunLink MCP 

6.0 

SunLink X.25 

6.0 

SunLink Channel Adapter SCA 

6.0 

SunLink CG3270 

6.0 

SunLink MHS 

6.0 

SunLink HSI 

6.0 

Notes; 


SunLink release 5.x products are only compatible with SunOS release 3.x. 
SunLink release 6.x products are only compatible with SunOS release 4.x. 
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Unbundled Languages 


Product Name 

Current Release 

Sun Modula-2 (Sun-2,3 and SunOS 3.x) 

2.0 

Sun Modula-2 (Sun-3,4,386/ and SunOS 4.x) 

2.1 

Sun FORTRAN* (Sun-2,3) 

1.0 

Sun FORTRAN* (Sun-4 and Sys4-3.2) 

1.05 

Sun FORTRAN* (Sun-2 and SunOS 4.0) 

1.1 

Sun FORTRAN* (Sun 386/ and SunOS 4.0) 

I.IR 

Sun FORTRAN* (Sun-3,4 and SunOS 4.0) 

1.2 

SPE for SCLisp 2.1 

1.0 

Sun Common Lisp-E 

1.1 

Sun Common Lisp-D 

2.1 

Sun Common Lisp-D (Sun-3, Sun-4)** 

3.0 

Cross Compilers (Sun-2,3,4 and SunOS 3.x,Sys4-3.2) 

2.0 

Cross Compilers (SunOS 4.x, Sun-3,4***) 

3.0 

Pascal**** (Sun-4 and Sys4-3.2) 

1.05 

Pascal**** (Sun-2,3,4,386/ and SunOS 4.0) 

1.1 

Notes: 


* The f 7 7 compiler is automatically included with SunOS Release 3.x, which 
includes SunOS Releases 3.2, 3.4, and 3.5. Sun FORTRAN 1.0 (for Sun-2,3 systems 
and SunOS 3.x), Sun FORTRAN 1.05 (for Sun-4 systems running Sys4-3.2), Sun 
FORTRAN 1.1 (for Sun-2,Sun386/ systems and SunOS 4.0), and SunFORTRAN 1.2 
(for Sun-3,4 and SunOS 4.0) are value-added products that support VMS extensions 
to the f 7 7 compiler, and must be purchased separately from the SunOS. 

There is no bundled FORTRAN or Pascal for Sys4-3.2 or SunOS 4.x. 

** Sun Common Lisp-D release 3.0 does not obsolete Sun Common Lisp release 2.1 
at this time. 

*** Runs on Sun-3,4 and produces output that also runs on Sun386/. 

**** The pc (Pascal) compiler is automatically included with SunOs Release 3.x, 
which includes Release 3.2,3.4, and 3.5. Sun Pascal 1.05 (for Sun-4 systems) 
and Sun Pascal 1.1 (for Sun-2, Sun-3, Sun-4 and Sun386/ 

systems running SunOS 4.0) are value-added products that support many extensions 
to the pc compiler, and must be purchased separately from the SunOS. 
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Unbundled Graphics 


Product Name 

Current Release 

SunGKS 

3.0 

SunPHIGS 

1.1 

Sun58TE 

1.0 


Unbundled Applications 


Product Name 

Current Release 

SunSimplify 

1.1 

SunTrac (Stm-2) 

1.2 

SunTrac (Sun-3,4,386/) 

1.3 

SunIPC 

1.1 

Transcript 

2.1 

SunUNIFY 

3.0 

PC-NFS 

3.0 

SunAlis 

2.1 

SunINGRES (Sun-2 and Sun-3) 

5.1 


Other Products 


Product Name 

Current Release 

News 

1.1 

NSE 

1.1 


TOPS Network Products 


Product Name 

Current Release 

TOPS for the PC 

2.1 

TOPS for the Sun Workstation (Sun-3, SunOS 3.5) 

2.1 

TOPS for the Sim Workstation (Sun-3, Sun-4, Sun386i, SunOS 4.X) 

2.2 

TOPS for the Macintosh 

2.1 

TOPS NetPrint 

2.0 


Current Sun Software The preceding tables contain lists of current Sun software products and their 

Products and Release Levels respective current release levels. 

You will note that the Software Technical Bulletin (STB) contains articles from 
time to time that detail technical changes in a given software product’s next 
available release. 
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Please contact your sales representative if you decide that you would like to 
update the release level of a Sim software product you already use, or wish to 
purchase another product. Use the tables to determine whether your release is the 
current release level. 

These tables appear monthly in the STB for your convenience. 
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D 
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troubleshooting printer, 569 
data alignment 
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SunUNlDFY 3.0 and beyond 2000,419 

dbx 
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Sun386/ ATbus drivers, 513 
DMA channels 

Sun386i ATbus, 510 
domain system 
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SunOS 386/ 4.0.1,635 

DOS 
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maximum open files, 257 
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DOS Windows 

1.0 announcement, 1156 
drivers 

Sun386/ ATbus, 510 
dtree 

displaying file trees, 260 

E 
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available Sun Courses, 349 
catalog, 778 
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checkmail Hackers’ Corner, 1083 
mush in Hackers’ Corner, 1349 

reporting bugs in CSD Europe, 229,339,495,621,740,879, 
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reporting bugs in Intercon, 233,343,499,625,744, 883, 
1012, 1136,1266, 1405 

reporting bugs in the US, 227,337,493,619,738, 877,1006, 
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end of life 

SunCGI and SunOS 4.1,564 
SunCORE and SunOS 4.1,564 
end-of-life plan 

Sun-2 languages, 415 
enscript 
hints, 1345 

environment variables 

Sun View windows, 1170 

EPS 

and SunWrite, 631 
errata, 1139 

dependency tables, 1015 
XView, 679 
error logging, 776 
error messages 
Ethernet, 84 
graphics, 785,786, 787 
ioctl, 787 
printcap tips, 1077 
errors 

Ethernet table, 90 
ioctl # 1C, 1053 
NFS write 13, 559 
es_f ile_read error 
fseek, 1058 
ESDI shoebox 
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ESDI shoebox, continued 

ordering information, 1099 
Ethernet, 24 

buffer management, 86 
error messages, 84 
error table, 90 
header, 24 
cthemet 

maximum interfaces, 256 
Ethernet 

memory management, 89 
panics, 90 
Sun-3 hardware, 84 
Sun386i pinouts, 1441 
Ethernet addresses 

Hackers’ Comer, 109 
expansion 

DOS expansion tip, 1429 
External Data Representation 
NFS in depth, 919 

F 

FCBs, 257 
features 

4.0.3 summaiy, 897 
fhandle 

NFS in depth, 921 
file control blocks, 257 
file handles 

DOS maximum, 257 
NFS in depth, 921 
file locking 

NFS in depth, 931 
file translation 
TOPS, 74 
file trees 

displaying, 260 

files 

maximum DOS open, 257 
filesystems 

kernel architectures, 755 
netgroups and NFS access, 1279 
on diskettes tip, 948 
find 

displaying file trees, 260 
flashing 

colormaps, 648 
floating point 

Sun-to-IBM conversion, 469 
floppy 

Sun386/ format, 911 
floppy diskettes 

creating Sun386/ UNIX filesystems, 420 
flushing 

cache, 51 

fonts 

error when missing, 1053 
LaserWriter n, 369 
format 

Sun386/ floppy disks, 911 
FORTRAN 


FORTRAN, continued 

cross-referencing in Hackers’ Comer, 1203 
dbx debugging hints, 703 
finding zero-divides, 947 
optimizing examples, 1199 
porting hints, 291 
SDRWAVE benchmark, 685 
short warning message, 563 
SunFORTRAN 1.2 announcement, 655 
undefined _units, 1058 
FP 

Sun-to-IBM conversion, 469 
FPU2 

and SunFORTRAN 1.2,655 
hardware and software support, 852 
fragmentation 

datagrams, 37 
FreeSpace 

saving disk space in Hackers’ Corner, 1433 
f seek 

es_f ile_read error, 1058 
FTP, 14 

function return values 

porting C to SPARC, 273 

G 

gateways, 34 

TOPS and PC-NFS, 241 
Germany 

uucico Consulting special, 259 
graphics 

error messages, 785,786,787 
ioctl error message, 787 
groups 

increasing inodes, 1019 
network filesystems, 891 
YP,891 

H 

Hacker’s Comer 

super kill skill, 299 
Hackers’ Corner 

checkmail, 1083 
Ethernet addresses, 109 
locate script, 713 
tar “i,837 
handles 

file, 257 
hardware 

and software dependencies, 1363 
dependency tables, 505 
Ethernet, 84 
questionnaire, 849 
Sun386j parallel port pins, 851 
Hardware Technical Bulletin 
hardware interest, 849 
headers 
IP, 23 
octets, 19 
overview, 21 
Hints and Tips 

modem installation, 95 
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Hints and Tips, continued 
modem problems, 100 
terminal installation, 95 
hotline@sun.COM 

reporting bugs, 227,337,493,619,738,877,1006, 1130, 
1260,1399 

hotlines 

world, 225, 335,491, 617,736, 875, 1004,1128,1258,1397 

HTB 

hardware interest, 849 

I 

IBM 

FP conversion to Sun, 469 
IBM PC 

TOPS, 68 
ICMP, 30 
IEEE 302.3 

and Sun386/Ethernet pinouts, 1441 
ilpr 

Interleaf to PostScript files, 915 
implementation architectures 
SunOS 4.1, 1047 
INGRES 

support transition, 561 
inodes 

maximum using mkfs, 1019 
inputs 

Sun-CGI-SunGKS, 1191 
installation 

Sun386/SunOS 4.0.1 remotely, 1021 
installations 

tapeless, 949 
Intercon 

hotline, 226,336,492,618,737, 876, 1005,1129,1259, 1398 
reporting bugs, 233,343,499,625,744,883, 1012, 1136, 
1266, 1405 

interface 

4.0.3 SCSI example, 811 
4.0.3 SCSI high-level driver theory, 821 
4.0.3 SCSI high-low, 801 
4.0.3 SCSI low-high, 807 
interfaces 

ethemet maximum, 256 
Interleaf 

to PostScript files, 915 
Internet 

addresses, 35 
domain system, 31 
protocols, 13 
Internet Protocol 

NFS in depth, 921 
subnetting, 650 
interrupt channels 

Sun386/ ATbus, 510 
ioctl 

# 1C errors, 1053 
error messages, 787 
IP, 13 

headers, 23 
NFS in depth, 921 
subnetting, 650 


ISO 

NFS in depth, 921 

K 

kernel 

architectures, 750 

architectures and kernel-level applications, 753 
debuggers, 246 
kernel architectures, 751 
arch(Jh 752 
device drivers, 758 
filesystem layouts, 755 
kernel-level applications, 753 
small kernels, 764 
sun3*, 750 
sun4*, 750 
visibility, 753 
kernel configurations 
SunOS 4.1,1049 
kernels 

small pre-configured, 764 
SunOS 4.0 profiling procedure, 583 
keyboards 

type 4 dip switches, 1234 
kill(l) 

Hacker’s Comer, 299 
kit 

SunOS 386/ 4.0.1 domestic, 635 


languages 

Sun-2 de-support, 415 
LANs 

and the Sun386/, 1104 
LaserJet n 

on Sun386/ parallel ports, 653 
LaserWriter n 
fonts, 369 
LaserWriters 

troubleshooting, 569 
layering 

mail, 19 
left shifting 

texted it bug, 1060 

lex 

Hackers’ Corner introduction, 1203 
line discipline 

changing characteristics, 645 
lint 

use during porting, 265 

Lisp 

new products, 895 

locate 

Hackers’ Comer script, 713 
locking files 

NFS in depth, 931 
lockscreen 

C2 and SunOS 4.0,526 
log 

errors, 776 
logging 
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logging, continued 

4.0.3 system daemon, 1281 
login 

Sun386/ security fix, 783 
logintool 

Sun386i security fix, 783 
loopback packets 
Sun386/, 893 

Ipc 

aborting printing daemon, 361 
unreliable daemon killing, 574 

Ipd 

troubleshooting, 569 

Ipq 

hints and tips, 1077 

Ipr 

hints and tips, 1077 
Is 

displaying file trees, 260 

M 

machdep.c 

SunOS 4.0.3 fix, 1286 
Macintosh 
TOPS, 66 
mail, 15 

layering, 19 

mush in Hackers’ Corner, 1349 
routing, 33 
manual pages 

printing using troff, 418 
mapping 

SunCGI-SunGKS calls, 1179 
maps 

customized YP, 516 
mass storage subsystems 

ordering information, 1099 
MC68020 

on-chip cache, 42 
memory 

DOS expanded tip, 1429 
textedit window maximum, 1171 
memory buffer 

error message, 787 
memory management 

Ethernet messages, 89 
messages 

valloc failed, 1420 
Micom-Interlan 5210 
driver upgrade, 416 
mkf s 

maximum inodes per group, 1019 
Sun386i UNIX filesystems, 420 
modems 

Hints and Tips, 100 
install Hints and Tips, 95 
null-modem cabling, 1095 
SPARCstation 1,1061 
Sun386/ serial cards, 1033 
monitors 

base size ordering, 1098 


monitors, continued 

corrupted Sun386i vi displays, 1197 
Sun386/, 984 
MS-DOS 

address space emulation, 510 
communications software, 1035 
Sun386r and modems, 1035 
multicast packets 
Sun386j, 893 
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